Use Visual Studio 2017 setup API to detect it in MsBuild module

[vbfox]

Use my VsWhere library to detect Visual Studio 2017 in MSBuild module.

It's the same thing as #1752 but it uses the COM API directly instead of the executable.

One important note is that NuGet is used instead of paket as the dependency can't be pulled on netstandard1.6 and must be conditional (They had removed most of COM)

Due to the netstandard1.6 strangeness I don't know if you'll take the PR but seeing the other one languish I wanted to propose an alternative

[matthid]

So the reference/package itself works with paket, only the condition is the problem, correct?

[matthid]

Also have you checked that it actually works on netcore? Only because the APIs are back doesn't mean they are working :).

[vbfox]

So the reference/package itself works with paket, only the condition is the problem, correct?

Yes the package works with paket we use it at my workplace but here paket can't have packages only for some framework AFAIK and trying to trick it via groups to do that is risky (don't know if possible) as dotnet pack need to work and generate the correct dependency list per-framework.

Essentially once the library isn't distributed for netstandard1.6 anymore it can go back to paket

Also have you checked that it actually works on netcore? Only because the APIs are back doesn't mean they are working :).

Oh yes they are here :) With Core 3.0 and winforms/wpf back microsoft will have managed a 360 of removing & adding back the whole framework

[matthid]

I almost see that as volunteering for maintaining the Fake.DotNet.MSBuild package ;)

Also, I'm actually not too concerned about dropping netstandard1.6.
There was never a stable fake 5 release running on netcore1.X.
Its very unlikely that someone is using the package and the netstandard1.6 binary within. We dropped it for another package not too long ago and nobody complained ;)

We can go for it and revert to your current solution if someone complains.

[vbfox]

I almost see that as volunteering for maintaining the Fake.DotNet.MSBuild package ;)

🤷🏻‍ I use it more than I change it but why not.

For the context I did that PR because I saw the other one and I had the code for that in a gist so it decided to clean it up, start using it at work instead of the MS interop package (And it's problems) and do a PR with it.

Also, I'm actually not too concerned about dropping netstandard1.6.

I wondered who was using that XD

[matthid]

Oh sorry I did an paket update as well for another reason. At least we will get rid of the old project files eventually. For now those files, pull and try again :)

[matthid]

Any interest in resolving the conflicts? ;)

[vbfox]

Il look at them (again 😁)

[vbfox]

Uh??? wait there was no conflicts ???

Well rebased anyway not that it cost anything.

[matthid]

hm either github failed to show properly or local git was clever enough to solve the conflicts? (or i failed ;))

[sliepie]

This #ifdef can now dropped, since now we target netstandard2.0 instead of 1.6?

[vbfox]

👍

[matthid]

I guess you have tested what happens when the COM-API is not available?

[matthid]

Let me remove the #if