Flowing the .NET SDK version dependency

[weshaggard]

We should pick the sdk version from the global.json file from arcade and flow that to the repo's that subscribe to arcade. The toolset needs to match so that we can ensure the tools we are building will run in the repo's that are consuming arcade, as well as we have a consistent toolset across the repos.

[markwilkie]

@mmitche - this keeps coming up. What's the current guidance?

cc/ @jcagme @tmat

[mmitche]

Wait until core-sdk onboards to BAR publishing.

[mmitche]

This is not required for preview 2

[jcagme]

Wait until core-sdk onboards to BAR publishing.

Since they are in, this something we could pick up, right?

[bricelam]

+1 Now that they publish to BAR, how do we do this?

Sdk/3.0.100-preview4-010612/dotnet-sdk-3.0.100-preview4-010612-win-x86.zip

It looks like their asset names include versions. Doesn't this prevent them from being referenced in Version.Details.xml?

[jcagme]

This needs changes in darc since it doesn't know about the existence of this version. Also, there are ongoing discussions on whether we should move to 3.0 yet or not. After that closes, I'll work on this change

[riarenas]

It looks like their asset names include versions. Doesn't this prevent them from being referenced in Version.Details.xml?

I'm going to follow the same approach we follow in dotnet/toolset. I'll create a fake internal package with a static name and that's the one that will be referenced.

[riarenas]

Focusing on this one again now that the urgent dependency update bug was taken care of.

[riarenas]

I see this issue as having two pieces:

1. Allowing repos to subscribe to the newest version of the SDK produced by core-sdk to enable different testing flows whenever a dependency subscription gets triggered. The only blocker for this is that right now core-sdk does not produce a stable asset name that repos can add to their dependencies. Should be unblocked with something like Add a fake nupkg project to be published to make dependency uptake ea… installer#1072

2. Automatically flowing the tools.dotnet node from Arcade's global.json to keep it in sync across all repos that have a subscription to Arcade so that the tooling used by Arcade SDK is consistent, and any features that depend on a new SDK version can be brought up without fear of breaking consumers that would have an older version. This doesn't depend on the versions that core-sdk updates, and instead will just happen whenever the version that arcade uses is manually updated.
   There is a possibility that a repo is using the version under tools.dotnet to drive some repo specific behavior, and syncing to the version Arcade uses will affect this behavior.

[markwilkie]

CCing @chcosta as he's working on a solution for multiple shared frameworks

[riarenas]

Part 1 of this issue should be ready. We'll need to wait for a clean build of Core-SDK for the new Microsoft.Dotnet.Sdk.Internal package to be produced so that repos can add a dependency to it.

Still working on updating the global.json sdk versions if they are older than what Arcade is flowing.

[riarenas]

The automatic flowing of the sdk version via Arcade dependency updates when the repo is using an older version of the sdk than what arcade uses has been rolled out, and today's dependency update PRs already include that. For example dotnet/coreclr#23718

The change to core-sdk publishing a stable package had to be reverted. And I filed #2426 to track re-enabling that flow.

Also filed #2427 so that we include that we're updating these versions in the PR description.