Ernst,
The assembly references in the project file (ie: .csproj) can be made strong enough so that the proper assembly is loaded in a side by side scenario.
This is important because in a future version of your application, you must properly create vNext proxy assemblies and project templates so that the end users of their application/VSTA do 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. Even without a new version number, the ShapeAppCSharpProxy reference can be distinct enough by specifying the unique PublicKeyToken
<
Reference Include="ShapeAppCSharpProxy, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3c3c0c46dd27dbcf" />
I think that there are two other attributes that you might use to reference the proper proxy assembly in add-in projects:
1. If version-specific proxy assemblies are installed SxS in the GAC, you could use the FusionName.
2. For a proxy assembly installed to a known Corporate/product location, you can provide a HintPath to the correct assembly.
Here's an example:
<
Reference Include="ShapeAppCSharpProxy">
<
Name>ShapeAppCSharpProxy</Name>
<
Aliases>ShapeApp Automation Library</Aliases>
<
HintPath>C:\Program Files\ISVName\ShapeAppCSharpProxy\Common\VSTA\ShapeAppCSharpProxy.dll</HintPath>
<
FusionName>ShapeAppCSharpProxy, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3c3c0c46dd27dbcf</FusionName>
<
SpecificVersion>True</SpecificVersion>
<
RequiredTargetFramework>3.5</RequiredTargetFramework>
</
Reference>