How to choose .NET Core SDK version?

[dedale]

Cf. https://github.com/dotnet/msbuild/issues/5706

Since the setup of VS 16.8 Preview, apps and unit tests depending on MSBuild seem to use .NET Core SDK 5.0.

After calling MSBuildLocator.RegisterDefaults(); I only have one VisualStudioInstance in MSBuildLocator.QueryVisualStudioInstances():

.NET Core SDK 5.0.100 C:\Program Files\dotnet\sdk\5.0.100-preview.8.20417.9\

Then, loading a .NET Core SDK project fails:

Microsoft.Build.Exceptions.InvalidProjectFileException : Invalid static method invocation syntax: "[MSBuild]::GetTargetFrameworkIdentifier('$(TargetFramework)')". Method '[MSBuild]::GetTargetFrameworkIdentifier' not found. Static method invocation should be of the form: $([FullTypeName]::Method()), e.g. $([System.IO.Path]::Combine(a, b)). Check that all parameters are defined, are of the correct type, and are specified in the right order. C:\Program Files\dotnet\sdk\5.0.100-preview.8.20417.9\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets

If I temporarily remove .NET Core SDK 5.0 folder, everything works fine. Instance loaded is:

.NET Core SDK 3.1.401 C:\Program Files\dotnet\sdk\3.1.401\

Thanks in advance for you help

[dedale]

Found out I can fix the issue with this global.json:

{
  "sdk": {
    "version": "3.1.100",
    "rollForward": "latestFeature",
    "allowPrerelease": false
  }
}

[kurtcodemander]

A long time ago I had the same issue and made a pull request for this. Unfortunately I lost my code locally so I never got around to fixing the things that was commented by JoeRobich yet.

But you can take a look here

Return all installed DotNetSDK versions

[KirillOsenkov]

Would it be possible to prioritize this? The experience is not great, you have a working build, you install 5.0 and your build suddenly breaks. The error message is also not helpful here.

[rainersigwald]

@kirillosenkov that is #92 and there's a PR out undergoing some additional testing (#106). In addition #79 is open to resolve this issue.

[jzabroski]

@rainersigwald If people want to use <RollForward>Major</RollForward>, then isn't a rule that disallows "future SDKs" bad? There is a co-constraint on the system which is this crazy RollForward stuff (that doesn't work right IMHO but is a different subect). Not trying to give you more headaches to think about. I personally think RollForward should die a peaceful death.

Edit: I will note, when I bring up RollForward and how it plays into how assemblies and their transitive dependencies get resolved, some people get into arguments with me about whether RollForward is compile-time redirect or deploy/run-time redirect. I think that's missing the point.

[rainersigwald]

@jzabroski fortunately we should be able to avoid that problem if we go with #106 as it's currently implemented--the value of Environment.Version is extracted well after any of the RollForward stuff has been handled, and should represent the actual selected runtime. So if you had a 5.0 application that gets rolled forward to 6.0 the version checked should be 6.0.

[jzabroski]

Ah, brilliant. I didn't grasp that from the PR. Thank you.