Description of the problem:

On a machine with VSTA v1 and VSTA v2 installed, compile the v2 ShapeAppCSharpAppAddIn project in the basic shapes sample.  You'll get this error:

Error 1 The type or namespace name 'ApplicationEntryPoint' does not exist in the namespace 'Microsoft.VisualStudio.Tools.Applications.Samples.ShapeApp' (are you missing an assembly reference?) C:\ShapeAppSamples\ShapeAppBasicCSharp\sample addIns\CSharp\AppLevel\SampleAppAddIn.Designer.cs 16 103 ShapeAppCSharpAppAddIn

There is similar problem in other samples, ie: Dynamic shapes sample ('DocumentEntryPoint')

Repro Steps:

1.          Create machine with VSTA 1.0 and VSTA 2.0 installed side by side.

2.          Install VSTA v 2, ShapeAppCSharp sample

3.          Open v2 ShapeAppCSharp sample add-in project and build.

4.          Build fails due to incorrect proxy assembly reference in the add-in project.

Why the failure?:

ProjectGen creates the project templates with an indeterminate  reference to the proxy like this in shapeappcsharpappaddin.csproj:

        <Reference Include="ShapeAppCSharpProxy" />

Unfortunately, ProjectGen does not generate other the assembly attributes.  It should include the version number, at the least.

This ambiguity will cause build errors or runtime errors for a VSTA add-in.

As noted:  for version 2 VSTA add-in sample projects, the add-in projects incorrectly resolve the ShapeAppCSharpProxy reference to the VSTA v 1 reference if it is available. 

( Even without a new version number, the ShapeAppCSharpProxy assembly reference in the shapeappcsharpappaddin.csproj  in the exsiting shapeappcsharpappaddin.csproj  can be made distinct enough by specifying the unique PublicKeyToken

<Reference Include="ShapeAppCSharpProxy, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3c3c0c46dd27dbcf" /> )

Impact on ISVs integrating VSTA:

This is an important issue to resolve because ISVs must properly create vNext proxy assemblies and project templates  for each version of their application.

ISVs must properly create vNext proxy assemblies and project templates so that when end users update their application, they will not encounter a problem building their add-in projects, new and existing, due to the project referencing the wrong version of a proxy assembly.

Renaming the proxy assembly for each version is not a desireable solution, from a maintenance perspective, but versioning the assembly is.

Steps to proper resolution of proxy assembly ambiguity:

1. Version your proxy assembly.

Using the SDK sample proxy and addin project shapeappcsharpappaddin.csproj  as an determinate example, we should

A.  update the version of the proxy assembly (ie: ShapeAppCSharpProxy, Version=2.0.0.0) and

B. include the correct version in the add-in project's reference to the ShapeAppCSharpProxy.dll:

shapeappcsharpappaddin.csproj, referencing version 1 proxy assembly:

<Reference Include="ShapeAppCSharpProxy, Version=1.0.0.0 />

shapeappcsharpappaddin.csproj, referencing version 2 proxy assembly

<Reference Include="ShapeAppCSharpProxy, Version=2.0.0.0 />

2.  There are other assembly reference attributes that ISVs might use to uniquely reference proxy assembly in their projects:

A.  If version-specific proxy assemblies are installed SxS in the GAC, they could use FusionName.

B.  For a SxS proxy assembly installed to a known ISV/product location, they can provide a HintPath to the correct assembly location.

For example, in shapeappcsharpappaddin.csproj:

<Reference Include="ShapeAppCSharpProxy">

  <Name>ShapeAppCSharpProxy</Name>

  <Aliases>ShapeApp Automation Library</Aliases>

  <FusionName>ShapeAppCSharpProxy, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3c3c0c46dd27dbcf</FusionName>

  <HintPath>C:\Program Files\ISVName\ShapeAppCSharpProxy\Common\VSTA\ShapeAppCSharpProxy.dll</HintPath>

  <SpecificVersion>True</SpecificVersion>

  <RequiredTargetFramework>3.5</RequiredTargetFramework>

</Reference>