global.json: tools.dotnet and sdk.version are redundant

[natemcmaster]

If you don't specify tools.dotnet in your global.json, you get this error:

/global.json must specify 'tools.dotnet'.

This seems redundant given that the sdk.version property already contains this information. Can we just use sdk.version since it's what VS and the CLI already use?

{
  "tools": {
    "dotnet": "3.0.100-preview-009750"
  },
  "sdk": {
    "version": "3.0.100-preview-009750"
  }

[tmat]

No, they have different semantics. The recommendation is to not set sdk.version.
See #320

[natemcmaster]

I read #320 and disagree with the conclusion you reached. It seems to me like we should be striving to use the product as is, and pushing the product team for changes when we can't use the product as designed.

That said, what's the harm in allowing us to use sdk.version instead of custom Arcade-only settings? Customers look to our code as an example of how to do things, and we prefer to avoid custom things like this. We've been pinning sdk.version for a long time and would prefer to keep it that way.

cc @markwilkie

[tmat]

My understanding is that we don't want customers to pin the SDK version. That's our official policy.

@livarcocc @nguerrera

[natemcmaster]

That may be the policy, but pinning is still supported, right? Over the last few years, we have found it necessary to pin SDKs in aspnet repos because pre-release builds regularly break us.

[tmat]

That may be the policy, but pinning is still supported, right?

It is indeed supported. There is nothing in Arcade blocking you from using it.

[markwilkie]

@natemcmaster - I agree we should be pushing the right changes to our products. In this case, what do you think the specific ask would be?

[natemcmaster]

1. Find solutions for the myriad problems @nguerrera listed in Reconsider requiring global.json to specify the SDK version #320. He listed enough which make it seem like global.json is effectively busted for anyone also using Visual Studio.
2. And/or update arcade to use sdk.version instead of tools.dotnet.

[tmat]

@natemcmaster I don't think we should tie specification of the toolset that is used for the build to the SDK pinning mechanism. You can control them separately. If you need to pin, then you can pin. If you don't than you don't need to.

The ideal process should be:

1. Start with not pinned to specific version - i.e. the latest installed on the machine is going to be used. This is good for discovering breaking changes early by dogfooding.
2. If you hit an issue with the dogfood build, file a bug, pin the sdk until the bug is fixed and then unpin it once you can move to the new build that has the bug fixed.

[natemcmaster]

What you are saying about pinning doesn't match the reality of how tools.dotnet works. Specifying dotnet.tools is effectively pinning. If you're truly advocating for not pinning, why doesn't the bootstrapper always install the latest SDK?

You can control them separately.

That doesn't currently seem realistic. The bootstrapper only reads tools.dotnet and throws an error if you don't specify tools.dotnet. (#1557)

If you hit an issue with the dogfood build, file a bug, pin the sdk until the bug is fixed and then unpin it once you can move to the new build that has the bug fixed.

For aspnet, this has been basically continually true, which is why we decide to always leave the SDK pinned.

[nguerrera]

There's a huge difference between downloading latest and using it for an official build (which I would NOT ever recommend) and allowing local IDE development with newer SDK (which I would recommend).

[natemcmaster]

I guess we just see this one differently. Our team prefers to have command line builds and Visual Studio doing the same thing. We used to let them diverge, but got burned enough times by differences in behavior between command line and Visual Studio. For the MSBuild experts on this thread, it may seem reasonable -- but you know what's going on and how to workaround it. The average contributor will more likely find this bewildering and frustrating.

[markwilkie]

@nguerrera and @livarcocc - let's chat a bit more about this and see what we can do to keep things moving forward.

[markwilkie]

Given the upcoming support for multiple shared frameworks (#1441) - does this provide a path forward without resorting to pinning @natemcmaster ?

[natemcmaster]

Not really. I think the path forward is to accept this a peculiar quirk of Arcade. Since I seem to be the only one requesting a change, closing.

[tmat]

The pinning will be addressed by https://github.com/dotnet/designs-microsoft/pull/44. Once implemented this will allow us to remove Arcade's tools.dotnet and use sdk.version.