search

haacked / Encourage

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

Clean up the required references #44

Closed haacked closed 7 years ago

haacked commented 7 years ago

I didn't need all the things I installed. Also added conditional references for VS 2015 and VS 2017.

haacked commented 7 years ago

So with this PR, I can successfully build and install the package using VS 2017. But if I build this in VS 2015, it successfully builds, but I get the following error when I double click the resulting VSIX...

@jaredpar @jcansdale any ideas?

4/21/2017 12:32:42 PM - Microsoft VSIX Installer 4/21/2017 12:32:42 PM - ------------------------------------------- 4/21/2017 12:32:42 PM - vsixinstaller.exe version: 4/21/2017 12:32:42 PM - 15.0.26403.7 built by: D15SVC 4/21/2017 12:32:42 PM - ------------------------------------------- 4/21/2017 12:32:42 PM - Command line parameters: 4/21/2017 12:32:42 PM - C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\VSIXInstaller.exe,C:\dev\play\encourage\EncouragePackage\bin\Release\Encourage.vsix 4/21/2017 12:32:42 PM - ------------------------------------------- 4/21/2017 12:32:42 PM - Microsoft VSIX Installer 4/21/2017 12:32:42 PM - ------------------------------------------- 4/21/2017 12:32:42 PM - Initializing Install... 4/21/2017 12:32:43 PM - Microsoft.VisualStudio.ExtensionManager.InvalidExtensionPackageException: The file is not a valid VSIX package. at Microsoft.VisualStudio.ExtensionManager.InstallableExtensionImpl.ReadVSIXManifestFromPackage(Stream stream, CultureInfo preferredCulture) at Microsoft.VisualStudio.ExtensionManager.InstallableExtensionImpl..ctor(String path, CultureInfo preferredCulture) at Microsoft.VisualStudio.ExtensionManager.ExtensionEngineImpl.CreateInstallableExtension(String extensionPath, CultureInfo preferredCulture) at Microsoft.VisualStudio.ExtensionManager.ExtensionEngineImpl.CreateInstallableExtension(String extensionPath) at VSIXInstaller.App.GetInstallableData(String vsixPath, Boolean isRepairSupported, IEnumerable1& skuData) at VSIXInstaller.App.Initialize(Boolean isRepairSupported) at VSIXInstaller.App.Initialize() at System.Threading.Tasks.Task1.InnerInvoke() at System.Threading.Tasks.Task.Execute()

jaredpar commented 7 years ago

Can you share out the VSIX?

haacked commented 7 years ago

Here you go.

Encourage.zip built with VS 2015

jaredpar commented 7 years ago

Took a look and the VSIX is fine. The problem is that you are, presumably, double clicking on this VSIX on a machine which has both VS 2015 and VS 2017 installed.

When that happens the VS 2017 version of vsixinstaller wins the file extension association. It refuses to recognize the VSIX as it isn't a V3 manifest and hence you end up with the error. If you run the VS 2015 installer directly against the VSIX it will install.

haacked commented 7 years ago

Took a look and the VSIX is fine. The problem is that you are, presumably, double clicking on this VSIX on a machine which has both VS 2015 and VS 2017 installed.

Correct

When that happens the VS 2017 version of vsixinstaller wins the file extension association. It refuses to recognize the VSIX as it isn't a V3 manifest and hence you end up with the error. If you run the VS 2015 installer directly against the VSIX it will install.

Weird. What am I doing wrong.

When I use VS 2017 to build this same solution, the VSIX produced installs into both VS 2017 and VS 2017. I added the Prerequesites section. I thought that was all I needed to make this a V3 manifest. Am I missing something?

jaredpar commented 7 years ago

Which VS version did you use to build the VSIX that you shared with me? Given the content of the VSIX and the mention of VS 2015 + VS 2017 in the PR title I just assumed you had built it with VS 2015. Should have been more explicit about that in my response.

The reason I assumed that is the VSIX doesn't contain a manifest.json or catalog.json file. Those are only produced via the VS 2017 SDK tooling and are necessary for a VS 2017 install. Try buliding with VS2017, unzip the VSIX and see if those files are present.

When I didn't see them, my brain defaulted to "@Haacked built that with VS 2015". :(

haacked commented 7 years ago

@jaredpar ah! Yes, the VSIX I shared with you was built with VS 2015. I was hoping that users of VS 2015 would still be able to build this project. Here's the one I built with VS 2017.

Encourage.zip built with VS2017

haacked commented 7 years ago

@jaredpar also, do the changes in this PR look good? I want to make sure Encourage still works on VS 2015 even without 2017. I tested on my machine, but I have both installed.

jcansdale commented 7 years ago

It looks like you need a <VsixType>v3</VsixType> in your .csproj. It seems this is implicit when compiling with VS 2017, but needs to be explicit for VS 2015.

I knew this was working for GitHubVS, so diffed my way to find the issue: https://github.com/github/VisualStudio/blob/master/src/GitHub.VisualStudio/GitHub.VisualStudio.csproj#L25

jaredpar commented 7 years ago

also, do the changes in this PR look good?

Yep they look good.

I want to make sure Encourage still works on VS 2015 even without 2017. I tested on my machine, but I have both installed.

Feel the pain here. It's hard to test and have confidence unless you have machines with single instances of VS installed. Otherwise you can get "lucky" by accidentally grabbing GAC entries from other VS.

Moving out of the GAC for VS 2017 should help this a lot. Until then though the best you can do is use full name references (which Encourage does). That's the best sanity check I've found to keeping my VS extensions running on all VS instances.

jcansdale commented 7 years ago

Just to record details from a Slack conversation with @Haacked.

It seems my testing wasn't up to scratch on commit 667f8bb. You can F5 in VS 2015 and 2017, but if you build the VSIX in VS 2015 and open using VS 2017 it fails (just like https://github.com/Haacked/Encourage/pull/44#issuecomment-296287372).

My previous comment about needing <VsixType>v3</VsixType> when running in VS 2015 seems to be correct. Unfortunately this only seems to work with Microsoft.VisualStudio.Sdk.BuildTasks.14.0. 😭

So to recap:

  1. <package id="Microsoft.VisualStudio.Sdk.BuildTasks.14.0" version="14.0.23-pre" ... /> Can be built in VS 2015 and VSIX installed with VS 2017 (with <VsixType>v3</VsixType> property). Unfortunately F5 always installs in VS 2015 so debug doesn't work.

  2. <package id="Microsoft.VSSDK.BuildTools" version="14.3.25420" ... /> Can be built in VS 2015 but install fails under VS 2017 (even with <VsixType>v3</VsixType> property).

  3. <package id="Microsoft.VSSDK.BuildTools" version="15.0.26201" ... /> Can't be build with VS 2015, but can be built with VS 2017 and VSIX works in VS 2015 (I think).

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).

Maybe @jaredpar could shed some light on how this is supposed to work?

jaredpar commented 7 years ago

Maybe @jaredpar could shed some light on how this is supposed to work?

Unfortunately no. The VSIX V3 upgrade experience was fairly painful for me to get it working on only VS 2017. Once I was done I considered adding round tripping support for VS 2015 but decided it wasn't worth the cost.

The approach I've taken now is I can actively develop the code in VS2013 - VS2017. But I will only produce a VSIX on VS2017.

haacked commented 7 years ago

The approach I've taken now is I can actively develop the code in VS2013 - VS2017. But I will only produce a VSIX on VS2017.

I think I'll do this.