DiscoveryType.VisualStudioSetup no longer works when upgrading to net60 explicitly targeting net60-windows/win-x64

[siegfriedpammer]

We are in the process of upgrading our test infrastructure to net60 and we are using MSBuildLocator.QueryVisualStudioInstances(new VisualStudioInstanceQueryOptions { DiscoveryTypes = DiscoveryType.VisualStudioSetup }) to get the location of msbuild.exe, which we need to perform out of process roundtrip testing of our decompiler (as can be seen here).

Could you please provide a Windows-specific build of this nuget package, which works with net60 and up and includes the FEATURE_VISUALSTUDIOSETUP features?

Either that, or:

• Fail fast with a NotSupportedException if DiscoveryType.VisualStudioSetup or DiscoveryType.DeveloperConsole are used, stating the reason - I had to decompile the nuget package to understand what was going on,
• Update the documentation and package description accordingly so that it says that (more than) half of the features are not available when using the nuget package with net or netcore
• and provide guidance on how to get the functionality, if it is not/no longer available using this official package - this is especially important because the classic framework will fade away sooner or later, leaving us in this "broken" state.

Alternatively, %PROGRAMFILES%\dotnet\sdk<version>\ could simply include a runnable msbuild.exe for people, who need it. But I guess, this would be a request for the dotnet runtime repo. I am just wondering, why nobody at Microsoft thought this might be useful and included it out of the box.

Thank you very much!

[dotMorten]

I believe DocFX is now also impacted by this since they moved to build on .NET 6+. Since it no longer can find visual studio, it falls back to the .net sdk, and fails to work on targets it doesn't support that we need the full msbuild for (UWP, Xamarin etc)

Could also be related to #120

[dotMorten]

I did a test if this and added the windows target. It only required a few pieces of code changes, to get this to run and pass with a net-windows target. I'll be more than happy to submit a PR to address this, if you're open to adding a windows specific build to this?
Branch: master...dotMorten:MSBuildLocator:net-windows

[rainersigwald]

That seems like a pit of failure to me. What do you do after you have found the MSBuild from VS that you can't load in your process?

[siegfriedpammer]

Then I guess the only sane thing is to fail fast with a NotSupportedException explaining the problem. Having to dig up the code of MSBuildLocator to understand what's happening is really bad UX.

[siegfriedpammer]

@dotMorten not sure if that's possible in your case, but I have switched all my projects requiring access to the MSBuild API from loading MSBuild in-process to Buildalyzer, which solved most of the platform/compatibility issues.

[hotchkj]

Deeply frustrating to find this, and thank you for doing the digging in the code to surface this. I spent some time building out a dotnet tool based on this library, only to find that the locator literally can't find Visual Studio, which renders it useless for our purposes. Now I have to write two variants, a framework exe for Windows usage (which can't even be a single easy to bundle executable file because that is only allowed for NET SDK as well), and a tool for all other use-cases.