[darc/maestro++] Update global.json with any SDK package depended on in Version.Details.xml

[dagood]

It looks like the global.json SDK package update functionality is limited to only a few hardcoded SDKs:

https://github.com/dotnet/arcade-services/blob/876268d727c0a5d3ec0a3f2840e9db35e20b467e/src/Microsoft.DotNet.Darc/src/DarcLib/DependencyOperations.cs

        public static readonly Dictionary<string, KnownDependencyType> _knownAssetNames =
            new Dictionary<string, KnownDependencyType>
            {
                {"Microsoft.DotNet.Arcade.Sdk", KnownDependencyType.GlobalJson},
                {"Microsoft.DotNet.Helix.Sdk", KnownDependencyType.GlobalJson},
                {"dotnet", KnownDependencyType.GlobalJson}
            };
// ...
            var dependencyMapping = new Dictionary<string, string>
            {
                {"Microsoft.DotNet.Arcade.Sdk", "msbuild-sdks"},
                {"Microsoft.DotNet.Helix.Sdk", "msbuild-sdks"},
                {"dotnet", "tools"}
            };

I was looking at creating an SDK package ("normal" MSBuild packages seem to have some limitations, especially during NuGet restore), but I noticed this hard-coded list that seems to be in the way.

Is there a reason these package IDs are hard-coded? Or am I mistaken?

@mmitche @JohnTortugo @riarenas

[dagood]

I guess it's not a big deal if it's easy to add them preemptively... the potential IDs I have in mind are:

• Microsoft.DotNet.Build.Tasks.SharedFramework.Sdk
  • Attempt to indicate similarity to Microsoft.DotNet.Build.Tasks.Packaging. (This SDK depends on that package.) This is a very rough SDK that is a min bar attempt to get WindowsDesktop out of Core-Setup.
• Microsoft.NET.SharedFramework.Sdk
  • When I get around to Create targets and tasks for authoring a shared framework #2704. ("Good" version of the above.)
• Microsoft.DotNet.SharedFramework.Sdk
  • In case NET is too official.

[mmitche]

Microsoft.DotNet.SharedFramework.Sdk

I like this one the best.

As far as why they are hard coded...I think primarily because there was originally one element to update. Feel free to add others. I'm not entirely sure where we would specify them that wouldn't end up being hard-coded in some fashion.

[dagood]

Microsoft.DotNet.SharedFramework.Sdk

I like this one the best.

Any objection to adding all three to avoid lag time later on?

My current plan is only to create Microsoft.DotNet.Build.Tasks.SharedFramework.Sdk, then later I will create one of the other two because there will be no compatibility between them.

I'm not entirely sure where we would specify them that wouldn't end up being hard-coded in some fashion.

Have publish metadata that specifies that a package is an SDK with a new attribute in BAR, enabled via a property in the SDK's csproj?

GlobalJsonMSBuildSdk="true" in Version.Details.xml?

[alexperovich]

The csproj for an sdk should just have <PackageType>MSBuildSdk</PackageType> that adds the right metadata into the nuspec. The BAR publishing stuff can read that.

[dagood]

I'm not too clear on the true classifications here, but the Packaging project has that and isn't what I think of as something that would go in the global.json:

arcade/src/Microsoft.DotNet.Build.Tasks.Packaging/src/Microsoft.DotNet.Build.Tasks.Packaging.csproj

Line 6 in 0f1befc

<PackageType>MSBuildSdk</PackageType>

But maybe that's harmless--I think it would only allow the package to be in a global.json, not prevent it from being used as an MSBuild tool package as well.

[dagood]

Adding the potential SDK names to the list is merged (dotnet/arcade-services#662), so I'm comfortable going ahead with my SDK package plans as is.

If it doesn't seem reasonable/worthwhile to implement generic SDK package global.json upgrade support (no big deal as far as I'm concerned, now that I got my IDs 😉), I suppose this issue can track the rollout of dotnet/arcade-services#662 and get closed after that.

[markwilkie]

Closing at 662 is merged.