make the workload resolver only light up for the specific entrypoint SDKs we control

[baronfel]

This is part of #26009

This makes NuGet/Home#13471 easier to diagnose because it removes the workload resolver from the list of resolvers - you can see the before and after here:

before:

D:\temp\test01\test01.csproj : error : Could not resolve SDK "MSTest.Sdk". Exactly one of the probing messages below indicates why we could not resolve the SDK. Investigate and resolve that message to correctly specify the SDK.
D:\temp\test01\test01.csproj : error :   SDK resolver "Microsoft.DotNet.MSBuildWorkloadSdkResolver" returned null.
D:\temp\test01\test01.csproj : error :   Unable to resolve 'MSTest.Sdk (= 3.3.1)' for '.NETStandard,Version=v0.0'. PackageSourceMapping is enabled, the following source(s) were not considered: Microsoft Visual Studio Offline Packages, NuGet official package source.
D:\temp\test01\test01.csproj : error MSB4236: The SDK 'MSTest.Sdk' specified could not be found.

after:

E:\Code\Scratch\test-app\test-app.csproj : error : Could not resolve SDK "MSTest.Sdk". Exactly one of the probing messages below indicates why we could not resolve the SDK. Investigate and resolve that message to correctly specify the SDK.
E:\Code\Scratch\test-app\test-app.csproj : error :   Unable to resolve 'MSTest.Sdk (= 3.3.1)' for '.NETStandard,Version=v0.0'. PackageSourceMapping is enabled, the following source(s) were not considered: nuget.
E:\Code\Scratch\test-app\test-app.csproj : error MSB4236: The SDK 'MSTest.Sdk/3.3.1' specified could not be found.

We save one line here, and with additional work on the MSBuild side we may be able to reduce the MSBuild resolver wrapper noise in this message.

[dsplaisted]

The workload resolver also resolves imports from workload packs, using the pack ID. So the pattern as is is insufficient. It needs to cover things like Microsoft.Android.Sdk.net9, Microsoft.NETCore.App.Runtime.AOT.Cross.net6.android-x86, and any other workload pack that has targets in it (normally these are imported via the WorkloadManifest.targets files).

[baronfel]

Thanks @dsplaisted - I checked on GitHub and made some regex patterns that would match all props/targets imports from the packs in the WorkloadManifests.targets that I found there. They are intentionally broad to help reduce the potential for missing something.

[dsplaisted]

Do you plan to try to do Microsoft.DotNet.MSBuildSdkResolver also? That could improve the perf and experience in Visual Studio and Full Framework MSBuild.

[dsplaisted]

Suggested change

	<ResolvableSdkPattern>Microsoft\.NET\.SDK\.WorkloadAutoImportPropsLocator|Microsoft\.NET\.SDK\.WorkloadManifestTargetsLocator|Microsoft\..*|Samsung\..*|GtkSharp\..*</ResolvableSdkPattern>
	<ResolvableSdkPattern>Microsoft\..*|Samsung\..*|GtkSharp\..*</ResolvableSdkPattern>

So it looks like anything starting with Microsoft., Samsung., or GtkSharp. will match. Given that, I don't think we need to special case the WorkloadAutoImportPropsLocator or WorkloadManifestTargetsLocator since they both start with Microsoft.

Did you look at all the packs from all the manifests (including Tizen) to make sure that they all match these patterns?

[baronfel]

Good call, I can remove the specific matches. These broad patterns are sufficient to cover all the packs I could find on github - so there is a risk that there's some workload that isn't OSS and is broadly used that these patterns wouldn't cover.

[baronfel]

Do you plan to try to do Microsoft.DotNet.MSBuildSdkResolver also

I certainly can - it should be pretty simple to do.

[baronfel]

@dsplaisted is the Microsoft.DotNet.MSBuildSdkResolver used by the .NET CLI, or just by VS? I was looking at it and it only targets net472? If not, what's used in the CLI to resolve the 'base' SDKs?

[baronfel]

This is every SDK that's included in-box today, matched explicitly for ease of review.

[dsplaisted]

All of them except FSharp.NET.Sdk and NuGet.Build.Tasks.Pack start with Microsoft. anyway. Do you think it's worth listing all those separately? It also means there will be more regexes to match.

[baronfel]

This is the content from the xml, just replicated in this 'generation' step for the .NET framework version of this resolver.

[dsplaisted]

If not, what's used in the CLI to resolve the 'base' SDKs?

I think that happens in MSBuild here: https://github.com/dotnet/msbuild/blob/main/src/Build/BackEnd/Components/SdkResolution/DefaultSdkResolver.cs

This works because with a .NET SDK install, MSBuild is already part of it so you can use a relative path from MSBuild instead of having to resolve an SDK version.

[dsplaisted]

All of them except FSharp.NET.Sdk and NuGet.Build.Tasks.Pack start with Microsoft. anyway. Do you think it's worth listing all those separately? It also means there will be more regexes to match.

[dsplaisted]

Looks like there are a bunch of Full Framework test failures, maybe something is off with the filter for that resolver.

[baronfel]

If not, what's used in the CLI to resolve the 'base' SDKs?

I think that happens in MSBuild here: https://github.com/dotnet/msbuild/blob/main/src/Build/BackEnd/Components/SdkResolution/DefaultSdkResolver.cs

This works because with a .NET SDK install, MSBuild is already part of it so you can use a relative path from MSBuild instead of having to resolve an SDK version.

Hilariously, after I asked this question Rainer and I spent 45m talking about the additions to the sdk resolvers required for dotnet/msbuild#11086 so I learned the answer that way 🗡️

Looks like there are a bunch of Full Framework test failures, maybe something is off with the filter for that resolver.

I'll do a bit of debugging today 👍

[baronfel]

After digging in a bit, the reason for the failures is that for full framework the MSBuildSdkResolver actually contains all of the different resolvers in a single assembly. The main reason for this is to prevent adding more assembly loads to VS, which regresses performance gates in that product.

What this means for this PR is that

• the netfx resolver XML file needs to have the combined set of patterns in it (which should be just <ResolvableSdkPattern>Microsoft\..*|Samsung\..*|GtkSharp\..*|FSharp\.NET\.Sdk|NuGet\.Build\.Tasks\.Pack</ResolvableSdkPattern>)
• this needs to be set in the MSBuild customizations and the static file
• I need to figure out how the xml static file would get bundled into the VS component - likely will need help from @joeloff on that once I get there.

[baronfel]

@joeloff I think this is the right place to add the generated resolver XML to ensure it gets added to the VSIX, but I don't know how to create/inspect the VSIX to verify. Any guidance I can follow here?

[joeloff]

The VSIX is just a zip, but it doesn't get produced in the SDK. We only generate the source (.swr file) and VS generates the actual zip, but if you do build -pack, you should end up with a file under artifacts\packages\Debug\NonShipping.

[baronfel]

Thanks, that's very helpful! I cracked open the SWR and found:

folder "InstallDir:\MSBuild\Current\Bin\SdkResolvers\Microsoft.DotNet.MSBuildSdkResolver\Microsoft.DotNet.MSBuildSdkResolver\"
  file source="$(PkgVS_Redist_Common_Net_Core_SDK_MSBuildExtensions)\MSBuildSdkResolver\Microsoft.DotNet.MSBuildSdkResolver\Microsoft.DotNet.MSBuildSdkResolver.xml"

That to me suggests that I have the layout incorrect because I believe the xml needs to be either adjacent to the dll, or in the SdkResolvers\<ResolverName>\<ResolverName>.xml layout pattern. So I'll need to go fix that.

That's validated by digging into the nupkg as well:

Here I can see that the directory structure is incorrect.