All geek questions in one place

As an extension, VS can use multiple versions with respect to Microsoft.VisualStudio. * Links?

Several extensions that I use are violated under VS2012, because at some point they were updated to work with VS2013, changing the version of the referenced libraries. At runtime, you can create this error:

Failed to load file or assembly "Microsoft.VisualStudio.Shell.12.0, Version = 12.0.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a" or one of its dependencies. The system cannot find the specified file.

  • I see various extensions referencing several versions of the same library:

    <Reference Include="Microsoft.VisualStudio.Shell.Interop" /> <Reference Include="Microsoft.VisualStudio.Shell.Interop.8.0, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" /> <Reference Include="Microsoft.VisualStudio.Shell.Interop.9.0, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

  • Others release the extension on the VS version.

  • Another option, according to this article , is to dynamically load the correct version.

I would like to help fix these extensions, but how to solve this problem?

+5
source share
2 answers

Thus, Visual Studio link assemblies are broken down into several different categories, which you must handle differently depending on the category:

  • Interlocked assemblies: - these are the ones you collected in your question. Each interop assembly is not a newer version of the same, but rather an assembly that contains all the COM interfaces that have been added to this version of Visual Studio. The link to the old versions is fine, just don’t link to a newer version than the lowest version of Visual Studio that you want to target.
  • Editors assemblies, Roslyn: Everything related to the main text editor (assemblies are Microsoft.VisualStudio.Text.Data, Microsoft.VisualStudio.Text.UI, Microsoft.VisualStudio.Text.UI.Wpf, and Microsoft.VisualStudio.Editor) , and Roslyn Visual Studio includes assembly redirects that redirect any version you link to to the VS version that you are actually running on. Re-specify the lowest version that you intend to support.
  • Microsoft.VisualStudio.Shell. [version]: it confuses people a lot. How this particular assembly works for each version of Visual Studio that comes with it, a new assembly name is created (with the version in the assembly). Then, in future versions of Visual Studio, we send a new version of the assembly that you are aiming for. So again, make sure you target Microsoft.VisualStudio.Shell. [Version] with the lowest version that you are going to support.

The difficult problem here is that the VSSDK project updates projects to upgrade your projects to newer versions. Start editing your MSBuild files manually to make sure that it does not, or lower what it already did. For the final VSIX, you send to users, who are often better, either build with an older version of VS to ensure that it will not collect new things by accident. If you want to use only the newer version, you will need to find the VS binaries from the older version that you want to use and check them in your version control system to make sure that the old versions are still compiled. Try your VSIX if you are following this route, as it is easy to make a mistake and accidentally refer to something new.

+9
source

I wrote an article discussing various version control policies used by Visual Studio assemblies.

http://tunnelvisionlabs.imtqy.com/vsbase/docs-master/html/edbfd3ce-43f4-4f3f-a90c-bc22bda19fae.htm

In addition, VSSDK. * NuGet packages use dependency declarations to help you determine the version of Visual Studio each extension can be used with.

The specific version of Microsoft.VisualStudio.Shell that you are referring to is the build with the version (in the previous article) and is included in the VSSDK.Shell.12 package, with the following description:

This package provides the Visual Studio Visual Studio reference assembly used by Visual Studio 2013 and later.

To easily configure both Visual Studio 2012 and Visual Studio 2013, use NuGet to manage VS SDK dependencies and provide the following conditions:

  • Make sure your build is not dependent on the VSSDK.IDE.12 NuGet package. This dependency means that one or more assemblies referenced by your project only work with Visual Studio 2013 and newer.
  • Make sure your build is not dependent on VSSDK.IDE.10Only , VSSDK.IDE.11Only or VSSDK.IDE.12Only . This indicates that your package refers to one or more assemblies that work only with a specific version of Visual Studio.

Ideally, you only need to install the NuGet VSSDK packages, which include the vs2012 and vs2013 tags .

+4
source

Source: https://habr.com/ru/post/1201565/

More articles:


All Articles