Add path to global.json SDK version lock

Builders of large systems often want to be able to explicitly specify an SDK version and avoid installing the CLI to a machine-global location.

Currently, global.json allows the version lock, but the specified version must be installed in either a machine-global location or a nonstandard location must be specified by the environment variable DOTNET_MSBUILD_SDK_RESOLVER_SDKS_DIR.

That environment means that you must launch Visual Studio from a specific environment to get the downloaded/private SDKs.

There could be an extension to the SDK resolver to respect a path specified in the global.json. Something like

{
    "sdk": {
        "version": "1.0.0",
        "path": "tools/downloadedsdk"
  }
}

could be equivalent to setting DOTNET_MSBUILD_SDK_RESOLVER_SDKS_DIR=%GlobalJsonPath%\tools\downloadedsdk before invoking the resolver.

This would be visible by any invocation (dotnet, msbuild, VS, or MSBuild API) since it’s file-based.

[KirillOsenkov]

After wasting another couple of hours on this today, I am more convinced than ever that we should allow specifying a path to the SDK in the global.json (as opposed to the environment variables, which are terrible UX for discoverability and automation). When you open the .sln in Visual Studio, for example, it doesn’t have the environment variables, and so the design-time build fails completely (you get errors like “System.Object not found”).

The tooling could even automate downloading the SDK into that folder instead of having arcane Arcade tools do it.

I have been shouting from the rooftops for years that for every repo in the .NET world anyone should be able to git clone && msbuild and it should just work, without custom build.cmd, build.sh etc. The environment variables get in the way of that. I absolutely do not buy the security argument because it doesn’t make the status quo any worse (any risks from building with a local SDK are already present when restoring and/or building with vanilla SDK as Alexander explains). Both the project source or any of the NuGet packages that are restored can be malicious.

Not to mention that the current status quo is you run build.cmd. And of course, it still builds with that custom SDK, which still entails the same alleged security risks.

By ignoring this problem we exclude a whole class of tools and automation from working out of the box. If any repo is buildable out of the box, you could run security analysis, semantic indexing for SourceBrowser or other code search tools, etc. etc. These tools can’t read your build.cmd as it’s totally opaque imperative code. Had we had declarative configuration in global.json (download and use this exact SDK), it would open doors to automating analysis etc. Opening the .sln in VS would always “just work”, whereas now it doesn’t and causes errors in the design-time build that only a few of us know how to deal with.

I think the current situation is a major source of friction in the .NET ecosystem.

[sandyarmstrong]

@richlander can you provide some more detail on the malicious scenario here? I don’t understand how this is riskier than restoring nuget packages.

Adding this info to global.json seems like the best way forward for painless IDE support of custom SDK locations on a per-solution basis.