Support for Visual Studio 2019?
nehme-bilal-ah opened this issue · 9 comments
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.
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.
- I am using MSBuildLocator 1.2.2.
- Both Visual Studio 15.9.6 and 16.0.0 are installed on my machine.
- I am not doing any manual finding/sorting, I am simply calling
MSBuildLocator.RegisterDefaults()as shown here.
Anything special I need to do to handle VS 2017 vs VS 2019?
RegisterDefaults takes the first instance that the VS Setup API returns:
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.
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?
What's the context your application runs in?
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).
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.
Sounds good, I'll try that, thanks!
@rainersigwald seems to work! I had to do a bit of string matching to find the right version (see here).