thibault-reigner
commented
4 years ago After some tests I have noticed that :
- some dependencies such as
Microsoft.VisualStudio.Setup.Configuration.Interopare targeting net framework only. - msbuild dlls loaded at runtime would be trying to load net framework dlls (such as mscorlib), hence triggering failure in tests hosted by a net core app (e.g : testhost.dll).
Hence making the possibility to make VS msbuild's location retrievable pointless anyway on Net Core.
Issue : On Net Core this target condition prevents one from retrieving the location of Visual Studio : https://github.com/microsoft/MSBuildLocator/blob/ed4fce73f2f946c08f7ecf6f2a9cb64b056003f5/src/MSBuildLocator/MSBuildLocator.cs#L310-L328
It seems to me that it is quite safe to remove it, as the current behavior (returning VS + DevCmd on Net Framework and .NET SDK on Net Core) is actually ensured by https://github.com/microsoft/MSBuildLocator/blob/ed4fce73f2f946c08f7ecf6f2a9cb64b056003f5/src/MSBuildLocator/VisualStudioInstanceQueryOptions.cs#L16-L25
As a result, calling https://github.com/microsoft/MSBuildLocator/blob/ed4fce73f2f946c08f7ecf6f2a9cb64b056003f5/src/MSBuildLocator/MSBuildLocator.cs#L74-L75 with the adequate value for
DiscoveryTypewould return VS locations on Net Core as well, instead of an empty sequence as currently.Reason In the company I am working for, we are slowly migrating from Net Framework 4.7.2 to Net Core 3.1, building all projects, regarding their framework with Visual Studio. Furthermore, for legacy reasons we still have some sql projects which can only be deployed (for instance to setup integration tests databases) through Sql Server Data Tools shipped with Visual Studio. We have written on Net Framework a piece of code which uses MsBuildLocator to finds VS msbuild, which can find SSDT files (located in the same folder). On Net Core, MsBuildLocator by default returns the location of SDK 3.1 which of course does not have such files, hence making tests fail.