search

microsoft / MSBuildLocator

An API to locate MSBuild assemblies from an installed Visual Studio location. Use this to ensure that calling the MSBuild API will use the same toolset that a build from Visual Studio or msbuild.exe would.
Other
218 stars 83 forks source link

Support for Visual Studio 2019? #63

Closed nehme-bilal-ah closed 5 years ago

nehme-bilal-ah commented 5 years ago

I am getting the following error which shows that MSBuildLocator is still linking to VS2017 instead of VS2019:

Errors: [Failure] Msbuild failed when processing the file 'C:\Users\Nehme\source\repos\UWPLib\Stubs\Stubs.csproj' with message: The imported project "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\WindowsXaml\v16.0\Microsoft.Windows.UI.Xaml.CSharp.targets" was not found. Also, tried to find "Microsoft\WindowsXaml\v16.0\Microsoft.Windows.UI.Xaml.CSharp.targets" in the fallback search path(s) for $(MSBuildExtensionsPath) - "C:\Program Files (x86)\MSBuild" . These search paths are defined in "C:\Users\Nehme\.nuget\packages\simplestubs\2.4.8.1\tools\Etg.SimpleStubs.CodeGen.exe.Config". Confirm that the path in the <Import> declaration is correct, and that the file exists on disk in one of the search paths.  C:\Users\Nehme\source\repos\UWPLib\Stubs\Stubs.csproj

This issue is blocking me from releasing a new working version of the mocking framework SimpleStubs.

rainersigwald commented 5 years ago

What version of MSBuildLocator are you using, what version(s) of VS are installed on the failing machine, and how are you finding/sorting the enumerated VS instances in your application? VS2019 support was added in #50, and seems to be working fine on my machine.

nehme-bilal-ah commented 5 years ago

@rainersigwald,

Anything special I need to do to handle VS 2017 vs VS 2019?

rainersigwald commented 5 years ago

RegisterDefaults takes the first instance that the VS Setup API returns:

https://github.com/Microsoft/MSBuildLocator/blob/bd25ad7a95d3e7f49403a1e597b2029f1e08367f/src/MSBuildLocator/MSBuildLocator.cs#L93

I don't know how that gets ordered; I tend to think of it as an unordered list. If your application would like to apply a versioning policy, you have to do it yourself, likely by calling QueryVisualStudioInstances and filtering/sorting the result according to your criteria.

nehme-bilal-ah commented 5 years ago

Ideally if the user is using VS2019, I'd like them to use the corresponding MSBuild, and same for VS2017. How can I achieve that?

rainersigwald commented 5 years ago

What's the context your application runs in?

nehme-bilal-ah commented 5 years ago

My application runs as a pre-build step during VS compile (to generate test stubs) but it's currently running within an exe (as opposed to a VS Task), so might not be possible to auto-discover the version of VS where it's running.

I might have to pass down that information to the exe (see here for more info).

rainersigwald commented 5 years ago

Yes, that makes sense. I think the best option would be to pass in $(VisualStudioVersion) which will be 15.0 for 2017 and 16.0 for 2019.

nehme-bilal-ah commented 5 years ago

Sounds good, I'll try that, thanks!

nehme-bilal-ah commented 5 years ago

@rainersigwald seems to work! I had to do a bit of string matching to find the right version (see here).