search

haacked / Encourage

A bit of encouragment added to Visual Studio
75 stars 32 forks source link

Fix vs2017 #45

Closed haacked closed 7 years ago

haacked commented 7 years ago

Make sure we properly reference these packages and conditionally apply them.

haacked commented 7 years ago

I think this now follows the advice @jcansdale noted in https://github.com/Haacked/Encourage/pull/44#issuecomment-297458275

Specifically, I'm doing this...

Conditionally importing 1. in VS 2015 and 3. in VS 2017 works, but isn't ideal. 😕 (this is what we're doing in GitHub for VS).

jcansdale commented 7 years ago

I've used this in a few projects now and it seems to work fine. We have a few VS 2015 holdouts on the GitHub for VS team, so it's kind of necessary. 😉

I'm guessing you could create a NuGet package that consolidates this hack. I.e. has dependencies on the 2 VS SDK packages and imports conditional targets/props. I'm guessing though because I've never done this kind of thing. I'm sure you if anyone would know!

I'd also be interested to get the official word from someone at Microsoft who know. What are the pitfalls of this approach? Is there a cleaner way. Not sure who to mention to find out.

jcansdale commented 7 years ago

@aarnott Has always been very helpful and opinionated when it comes to MSBuild related stuff. 😉 Maybe he would have some pointers?

AArnott commented 7 years ago

Is the goal to just get it building in VS2015 but for official releases you'll use VS2017?

AArnott commented 7 years ago

@tinaschrepfer, When VS2015 builds a project that uses the VS2017 build tools (which I would expect to work since it's based on nuget packages), the build fails with this:

The "GetExtensionsPath" task failed unexpectedly.
System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.VisualStudio.Settings.15.0, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
File name: 'Microsoft.VisualStudio.Settings.15.0, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at Microsoft.VsSDK.Build.Tasks.GetExtensionsPath.Execute()
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

It looks like we're missing an assembly in the packaging. If this is supposed to work, is there a bug for fixing this?

jcansdale commented 7 years ago

@AArnott thanks for looking into it!

Is the goal to just get it building in VS2015 but for official releases you'll use VS2017?

In GitHub for VS, we want to be able to build and debug with either (from inside VS). Our external build is still using 14.0.

Unfortunately each NuGut package has a gotcha. See https://github.com/Haacked/Encourage/pull/44#issuecomment-297458275

  1. <package id="Microsoft.VisualStudio.Sdk.BuildTasks.14.0" version="14.0.23-pre" ... /> + <VsixType>v3</VsixType> F5 always installs in VS 2015 so debug doesn't work in VS 2017.

  2. <package id="Microsoft.VSSDK.BuildTools" version="14.3.25420" ... /> Doesn't support VSIX v3, so install fails on VS 2017 (although F5 does work on VS 2017).

  3. <package id="Microsoft.VSSDK.BuildTools" version="15.0.26201" ... /> Build fails on VS 2015 (as @AArnott details above).

The workaround is to conditionally use 1. and 3. (depending on version of VS running).

The be consistent with how we use other VS SDK NuGet packages (i.e. reference 14 if you want compatability with VS 2015 and above), it would be nice if there was a version of Microsoft.VSSDK.BuildTools v14 that supported VSIX v3. I thought adding a <VsixType>v3</VsixType> property might work, but it didn't. 😢

@tinaschrepfer, what am I doing wrong? 😕

haacked commented 7 years ago

@AArnott as @jcansdale points out, I'd like to be able to build and release it with both VS2015 and VS2017. If someone forks it and builds with 2015, I'd like their extension to work with both.

Right now, I can only build working VSIX packages with 2017. I'm OK with that for the time being.

AArnott commented 7 years ago

I think the only way to get your VSIX to work in VS2017 will require building with the 15.x buildtools sdk package. If a future update to that nuget package can fix it so it works in VS2015, then great. Tina will have to comment on the feasibility of that though.

haacked commented 7 years ago

If a future update to that nuget package can fix it so it works in VS2015, then great. Tina will have to comment on the feasibility of that though.

While that would be great, it'll become less and less important over time.