A VSX based add-in developed in Visual Studio 2010 returns a runtime error when hosted by Visual Studio 2013

Question

I have written a Visual Studio Package based add-in for Visual Studio 2010.  I works perfectly when run within Visual Studio 2010.

I would like to migrate it to Visual Studio 2013, but am getting a run time error when I try to use the add-in in Visual Studio 2013.

The statement "VCProj = (VCProject)proj.Object" works in visual studio 2010 but throws a System.InvalidCastException in visual studio 2013.

To be clear, this is a runtime error.  Both Visual Studio 2010 and 2013 compile the VSX project without error.

VCProject's fully qualified namespace is "Microsoft.VisualStudio.VCProjectEngine.VCProject."
the "proj" object's fully qualified type is "EnvDTE.Project."

This project is a C# project, a visual studio package to be specific.  It is a C++ App (creating) Wizard that works perfectly when hosted by Visual Studio 2010.

Any helpful advice you can provide will be appreciated.

---

Charles S. Cotton

Answer 1

AFAIK, the VCProject*.dll assemblies are version-specific, different for each VS version. So you need two projects, one for each VS version, referencing the correct VCProject*.dll assemblies, that generate different packages.

BTW, the term "add-in" refers to an old extensibility technology. The correct technical term is "package".

---

My portal and blog about VSX: http://www.visualstudioextensibility.com
Twitter: https://twitter.com/VSExtensibility
MZ-Tools productivity extension for Visual Studio: http://www.mztools.com

Answer 2

Thanks again, Carlos, for your help.

When I first opened the VS 2010 solution file in VS 2013, it went through some kind of conversion process.  Did not this conversion process update the VCProject.dll assembly references to the correct version?

How do I check?  I don't know how to fix the problem using the information you have provided.  I'm mostly a C++ programmer forced to use C# to create an add-in, I mean a package.

I originally wrote these as add-ins and then refactored them as VSX packages, when I read that the add-in tech was being deprecated. 

I did however google the term 'AFAIK' which, at first I thought was a C# term, but which turns out to be internet lingo ("As Far As I Know").

ASFAMUOFTTAIIC, FYI I call the toolbar included in my VSX Package "VSP Add-Ins."  I use the term VSP (Visual Studio Package) because I don't know what the X in VSX stands for!

By the way, "ASFAMUOFTTAIIC" stands for "As far as my use of the term add-in is concerned"  

Thanks again for your help!

 

---

Charles S. Cotton

Answer 3

Hi Charles,

OK, I see that you know the add-in vs package difference :-)

You can check the version in the References node of your project. Select the reference and in the Properties window check the Version field.

---

My portal and blog about VSX: http://www.visualstudioextensibility.com
Twitter: https://twitter.com/VSExtensibility
MZ-Tools productivity extension for Visual Studio: http://www.mztools.com

Answer 4

Hi Carlos,

Well, that fixed the problem!  To build a VS 2013 version of my package, I performed the following steps:

Copied the four solution and project files, renaming them with a '2013' suffix.

I then hid the original 2010 versions in a 2010 folder temporarily, just to protect them from the VS 2013 conversion process. 

I opened the 2013 solution file in VS 2013, removed the now missing project file, added the 2013 'suffixed' project file back and then VS 2013 performed the one time conversion on the project files.

In project properties, I changed the NET version from 4.0 to 4.5 which is necessary to see the 12.0 version of VCProjectEngine.  I removed the 10.0 version and added the 12.0 version of VCProjectEngine references.

This fixed the problem with my add-in (you know what I mean)!

There is one file "source.extension.vsixmanifest" that specifies the visual studio versions that are 'targets' of the package that required that I create separate copies for VS2010 and VS2013.  I had to create a 2010 and 2013 folder and put a copy of this file in each of these folders as the compiler wouldn't recognize the file if I merely renamed them with the 2010,2013 suffix for some odd reason.  If there is a way to rename this file to, say source.extension.2010.vsixmanifest, for example and have the compiler use the renamed file, I wouldn't mind learning how...

Thanks again!

---

Charles S. Cotton