locked
Development and deployment of visual studio addin for 2010 & 2012 RRS feed

  • Question

  • I have developed an addin for visual studio 2010, which performs custom task on TFS workitems (via button click & context menus).

    The addin works fine with vs 2010. Now the requirement is to make it compatible with vs 2012 (and possibly for future version).

    Here are the references,

    i.stack.imgur.com/Q6liD.png

    The addin doesn't work in VS 2012. If I update the host value in `.addin` file and try to load it, the team explorer crashes / or the addin doesn't work. Researching a bit reveals that the references (assemblies, `Microsoft.visualstudio.Teamfoundation.*.dll`s) for VS 2012 are compiled in .Net 4.5. 

    If I upgrade the solution, upgrade the references and set target framework to .NET 4.5, the addin works for VS 2012. However, as expected it doesn't work for VS 2010.

    So now I have two projects with same source code but with different  target framework & VS version.

    The question is:

    How can I manage source code efficiently, I don't want to keep two set of source files. It will become hard to maintain in future.

    How to deploy them. As VS 2012 doesn't support simple deployment, I used wix. A wix project is now added to each solution and the MSI is working fine. But this will make two different installer. How can I make it one installer for both version (and possibly future versions as well)?


    Sunday, December 15, 2013 6:42 AM

Answers

  • Hello,

    There are several approaches:

    1) Single source code base, single output binary dll for all VS/TFS versions:

    In this case the source code base can only reference the dlls of the minimal VS/TFS version. This approach works for sure for VS (see my article HOWTO: Create an add-in that targets several Visual Studio versions with the same add-in DLL using C# or VB.NET.) because:

    - In some cases, VS 2012 uses exactly the same dlls than VS 2010 (EnvDTE, EnvDTE80, Microsoft.VisualStudio.Commandbars, etc.)

    - In other cases, VS 2012 provides new dlls but are backwards compatible, so the devenv.exe.config file at "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE" includes redirections from 10.0 assemblies to 11.0 assemblies.

    But I am not sure if it works for TFS, that is, if the Microsoft.TeamFoundation.* and Microsoft.VisualStudio.TeamFoundation.* dlls of TFS 2012 are backwards compatible with those of TFS 2010. I suspect that not.

    2) Single source code base, two output binary dlls

    In this case you create a single solution with two projects (one referencing TFS 2010 dlls and the other TFS 2012 dlls) but both include the same code files, so maintenance is good. You can even define a compilation constant on each project properties (ex: TFS2010, TFS2012) and in the code use conditional compilation when required:

    #if TFS2012
    ...
    #elif TFS2010
    ...
    #endif

    About the setup, it is quite easy. The examples of the first four articles under the section Articles about installing and uninstalling of my web page http://www.mztools.com/resources_vsnet_addins.aspx assume a single setup that installs a different dll for each VS version.



    MZ-Tools: Productivity add-ins for Visual Studio: http://www.mztools.com. My blog about developing add-ins: http://msmvps.com/blogs/carlosq/


    • Edited by Carlos J. Quintero Sunday, December 15, 2013 10:33 AM fix
    • Proposed as answer by Carlos J. Quintero Sunday, December 15, 2013 10:34 AM
    • Marked as answer by Web-E Sunday, December 15, 2013 11:34 AM
    Sunday, December 15, 2013 10:33 AM

All replies

  • Hello,

    There are several approaches:

    1) Single source code base, single output binary dll for all VS/TFS versions:

    In this case the source code base can only reference the dlls of the minimal VS/TFS version. This approach works for sure for VS (see my article HOWTO: Create an add-in that targets several Visual Studio versions with the same add-in DLL using C# or VB.NET.) because:

    - In some cases, VS 2012 uses exactly the same dlls than VS 2010 (EnvDTE, EnvDTE80, Microsoft.VisualStudio.Commandbars, etc.)

    - In other cases, VS 2012 provides new dlls but are backwards compatible, so the devenv.exe.config file at "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE" includes redirections from 10.0 assemblies to 11.0 assemblies.

    But I am not sure if it works for TFS, that is, if the Microsoft.TeamFoundation.* and Microsoft.VisualStudio.TeamFoundation.* dlls of TFS 2012 are backwards compatible with those of TFS 2010. I suspect that not.

    2) Single source code base, two output binary dlls

    In this case you create a single solution with two projects (one referencing TFS 2010 dlls and the other TFS 2012 dlls) but both include the same code files, so maintenance is good. You can even define a compilation constant on each project properties (ex: TFS2010, TFS2012) and in the code use conditional compilation when required:

    #if TFS2012
    ...
    #elif TFS2010
    ...
    #endif

    About the setup, it is quite easy. The examples of the first four articles under the section Articles about installing and uninstalling of my web page http://www.mztools.com/resources_vsnet_addins.aspx assume a single setup that installs a different dll for each VS version.



    MZ-Tools: Productivity add-ins for Visual Studio: http://www.mztools.com. My blog about developing add-ins: http://msmvps.com/blogs/carlosq/


    • Edited by Carlos J. Quintero Sunday, December 15, 2013 10:33 AM fix
    • Proposed as answer by Carlos J. Quintero Sunday, December 15, 2013 10:34 AM
    • Marked as answer by Web-E Sunday, December 15, 2013 11:34 AM
    Sunday, December 15, 2013 10:33 AM
  • Thanks for the help. I took the second approach. Added source code files as link to the new upgrade project, upgraded references & compiled it in 4.5. I guess I can work with these two project output and Wix to deal with the setup. 

    Thanks for the links, your site was a starting point for me when I started developing addins. :)

    Sunday, December 15, 2013 11:38 AM