Resign DLL : VS2010 SP1 bug in vcxproj properties DelaySign\KeyFile

Jan 15, 2013 at 12:39 PM

I've just finished a migration of 600 projects from VS2005 to 2010 using Multi-Targeting .NET 2 and VS2005 toolset
That would not have be possible whitout your targets files, thanks!
Still multitargeting leads to a ton of problems, not documented anywhere...
Only remark is that there is still an open issue using your targets.
Migrating Native VC++ vcproj to VS2010 will create new vcxproj
That means that when you compile you'll NOT be able to resign your dll because of the (in)famous VS2010 SP1 bug involving vcxproj properties DelaySign\KeyFile
In my case I had already modified my VS210 target files (and Vs2012 as well, a bit differently)
But when you use Multitargeting, VS2010 will not use his own target files but the ones in V80 directory, so they MUST be modified as well to fix DelaySign\KeyFile
So maybe, just a suggestion, you could already provide you v80 files fixing that issue , or in a separate msi


Is same fix proposed by Microsoft for VS2010 in 

In file :
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\PlatformToolsets\v80\Microsoft.Cpp.Win32.v80.targets

Modify DelaySign\KeyFile as below:

  <Target Name="Link"  Condition="'@(Link)' != ''">


DelaySign   ="$(LinkDelaySign)"
KeyFile     ="$(LinkKeyFile)"

  <Target Name="LinkEmbedManifest"


DelaySign   ="$(LinkDelaySign)"
KeyFile     ="$(LinkKeyFile)"


Jan 15, 2013 at 6:49 PM
Edited Jan 16, 2013 at 3:30 AM

I was not familiar with the proposed fix for this problem, as I already used a post-build task for assembly signing. Reading the MSDN blog post you reference, it sounds like the proposed changes to the LinkEmbedManifest task change the behavior back to VS 2010 RTM, which is still incorrect. According to the article, the VS 2010 RTM problem is fixed by changing the typo in the Link task. So, it's not entirely clear to me whether changing *both* is desirable. If you have made both suggested changes, can you now specify the keyfile name in the linker properties as intended, or must you still use 'additional options'?

Jan 16, 2013 at 3:29 AM

I did a bit of testing and satisfied myself that the changes should be made in both tasks. I've committed the changes and updated the MSI. Please test the new MSI and report back here whether it works the way you expect. Thanks for the excellent feedback!

Jan 16, 2013 at 11:54 AM

I'm new in this company but, from what I've understood, the history goes more or less like below.

1)Original Visual Studio 2005 solution contains C++,C# and VB projects
  To sign the dll C++ projects use  the Linker properties "Key File=PATH\Key.snk" and "Delay Sign = No"
  This is still maintained because many servers still need to be migrated to .NET 4

2)From 2005 solution has been created a new Visual Studio 2010 solution with same projects using .NET 4
  As explained in the article "", VS2010 RTM a.Assemblies built using C++ projects were not getting signed at all.
  So they implemented the recommended workaround and used a Post Build Step to do the signing

3)The moment we upgraded to VS2010 SP1 ,  the VS2010 RTM workaround was broken, nor we wanted revert the PostBuildStep modification for all projects
  So we implemented the change (2.d.A) in  "Microsoft.Cpp.Win32.targets" that so fixed out PostBuildStep resigning (sn.exe –R...)

4)We're now migarting to TFS that doesn't support anymore VS2005, so we started investigating the Multitargeting to port our still existing VS2005 into VS2010 while maintaining the VS2005 toolset and .NET 2
  As already explained, the moment you migrate vcproj into VS2010 vcxproj, you get into same troubles
  In this case original VS2005 projects still  sign using  properties File=PATH\Key.snk and Delay Sign = No ( so not using the PostBuildStep)
  Form that the need to apply the fix in Microsoft.Cpp.Win32.v80.targets for both Key File\Delay Sign

5)This was just a Proof Of Concept(POC), jssut to be able to compile, no validation of the produced dll has been done yet
  Shortly we'll decide if to go this road
  In this case I will do more testing and redo all migration and be able , and more then happy, so to test you modified msi