VSTA version compatibility

Q:

I have a couple of questions about version compatibility.

1)       Will a compiled VSTA 2.0 add-in run in a VSTA 1.0 environment? 

2)       What about recompiling a VSTA 2.0 project in a 1.0 environment?  Will this work?

A:

Due to the technical merit of VSTA’s runtime it was added to the .NET 3.5 framework System.Addin namespace with further refinement and abstraction.

The VSTA team adopted the .NET 3.5’s System.Addin approach with VSTA 2.0, making breaking changes in the runtime integration (add-in loading, activation, proxied types) and add-in new add-in assembly attributes.  We expect this to be a one-time occurrence, so not a good case for setting multi-year/multi-version policy.  I would expect future versions of System.Addin-based add-in development to maintain a stable migration path due to System.Addin’s widespread adoption (.NET BCL, VSTO, VSTA).  Going forward, add-ins of any version can be loaded by any version of their host application, because they communicate through a proxy assembly that any version of the host can load.

Let’s assume, for this discussion, that Program1 uses VSTA1.0 and Program2 uses VSTA2.0…

*         VSTA 2.0 requires .NET 3.5 at runtime.  3.5 is really a superset of .NET 2.0, used by VSTA 1.0

All host application assemblies and VSTA 2.0 integration, proxy and addin assemblies must run in .NET 3.5

“If you look at the '.NET 3.5' mscorlib, it says it is metadata version 2.0.0.0 (unchanged from .NET 2.0) You can look at the file version to identify the actual version of the assembly. With .NET 3.5 installed on a system, for example, the mscorlib.dll in the v.2.0.50727 folder is the .NET 3.5 one (file version 2.0.50727.1433), not the .NET 2.0 one (file version 2.0.50727.42).”

*       Add-in Discovery/Loading/Activation

VSTA 1.0 host establishes path to add-in and loads it.  Activation uses TypeInfrastructureManager on host side

VSTA 2.0 vsta pipeline establishes path to add-in and loads it. Activation uses ITypeMapProvider and add-in assembly attributes

Backward Compatibility:  Program2 application would have to support separate code paths to load 1.0 and 2.0 addin assemblies, and install 1.0 and 2.0 runtime assemblies side-by-side

Forward Compatibility:  Program1 cannot load VSTA 2.0 add-ins without rebuilding them as VSTA 1.0 add-ins.

*         Add-in Proxy version (Program proxy assembly and VSTA 1.0 runtime integration assemblies)

VSTA 1.0 proxy references Microsoft.VisualStudio.Tools.Application.Adapter and Microsoft.VisualStudio.Tools.Application.Contract

Program2 (VSTA 2.0) proxy assembly references Microsoft.VisualStudio.Tools.Applications.Runtime.v9.0

Backward Compatibility:  Program2 (VSTA2.0) would install Program1 and Program2 proxy and runtime assemblies.

Forward Compatibility:  Program1 cannot load Program2 (VSTA 2.0) add-ins without rebuilding them to reference the Program1 proxy assembly (and VSTA 1.0 runtime assemblies implicitly)

*        Add-in Projects/Assemblies

VSTA 1.0 Add-in projects have no entry class discovery/activation attributes and open in VSTA/VS 2005. 

VSTA 2.0 Add-in projects/assemblies have entry class attributes for discovery/activation:

    [System.AddIn.AddIn("AppAddIn", Version = "1.0", Publisher = "", Description = "")]

and open in VSTA/VS 2008

Program1 Add-in projects reference Program1 proxy assembly and can migrate to VSTA 2.0 when rebuilt as VSTA 2.0 project/assembly

Program2 (VSTA2.0) Add-in projects reference Program2 (VSTA2.0) proxy assembly and cannot open, build, or run in Program1/VSTA1.0,

*         Source Code

VSTA1.0 Add-in source is compiled using VC# 2005

Microsoft (R) Visual C# 2005 Compiler version 8.00.50727.42 for Microsoft (R) Windows (R) 2005 Framework version 2.0.50727

VSTA2.0 Add-in source is compiled using VC# 2008

Microsoft (R) Visual C# 2008 Compiler version 3.5.21022.8 for Microsoft .NET framework version 3.5

Now, to answer your specific questions:

1)     Will a compiled VSTA 2.0 add-in run in a VSTA 1.0 environment?  

No, not without being rebuilt as a VSTA 1.0 add-in assembly …

2)    What about recompiling a VSTA 2.0 project in a 1.0 environment?  Will this work?

Yes, as long as the object model usage and language usage is compatible.  Except for the breaking changes introduced with VSTA 2.0, add-ins are ‘version-resilient’ (backward/forward compatible), because they use a proxy assembly that any version of the host application can load.  This means that recompiling v2+ add-ins should be unnecessary, and that add-ins will be compatible with versions of the application both backwards and forwards.  We have not seen Microsoft support VS projects that will open in older versions of VS/VSTA and Microsoft will probably only provide helper code to migrate VS projects to newer versions.  But I think that the ISV could create their own project migration helper that will migrate projects backwards and forwards.