none
VS 2010 SP1 brakes strong name signing - critical bug

    Question

  • After installing VS 2010 SP1 last night all our builds that have C++/CLI assemblies broke. The reason is that project file format have been changed. In VS 2010 RTM key file settings looked like this:

    <Link>
     <KeyFile>...</KeyFile>
    </Link>
    
    

    In VS 2010 SP1:

    <PropertyGroup>
     <LinkKeyFile>...</LinkKeyFile>
    </PropertyGroup>
    
    What are our options?
    Wednesday, March 09, 2011 4:26 PM

Answers

  • Hi,

    My name is Amit Mohindra and I’m Program Manager with the MS Visual C++ team.

    We recognize that a change in the assembly signing process in SP1 has introduced an unintentional breaking change and we are sorry for the inconvenience caused by this issue.

    I have detailed the cause and potential workarounds for this issue in the following blog.

    http://blogs.msdn.com/b/vcblog/archive/2011/03/11/10140139.aspx

    Please feel free to contact me at "amitmo(at)microsoft(dot)com" if you have further issues or questions and I will be happy to assist.

    Thanks,

    Amit

    Saturday, March 12, 2011 11:18 PM

All replies

  • I see the same issue. Does it not fix the problem if you update the project files?


    Tore Østergaard
    Oticon A/S, Denmark
    Wednesday, March 09, 2011 5:12 PM
  • It does, but:

    1. It is not acceptable that service pack introduces such a breaking change.

    2. You cannot build the same project in VS 2010 RTM and VS 2010 SP1.

    Wednesday, March 09, 2011 5:55 PM
  • I totally agree with you Alex. Just wanted to hear if you got things working again, because I run into other problems when fixing the above.

    I will do more investigations tomorrow and report back.


    Tore Østergaard
    Oticon A/S, Denmark
    Wednesday, March 09, 2011 9:10 PM
  • It seems that you can use both constructions in the same file. VS 2010 RTM will use the 'old' construction and VS 2010 SP1 will use the new construction (the problem is documented in the VS 2010 SP1 release notes).

    I was hoping that this fix would also resolved:

    mt.exe : general warning 810100b3: ..\..\..\bin\Debug\amil_gl.dll is a strong-name signed assembly and embedding a manifest invalidates the signature. You will need to re-sign this file to make it a valid assembly.

    as the SP1 release notes describe that a custom build step is not needed anymore. I need still however a custom buildstep to re-sign the assembly after mt.exe runs. Do I miss something?

     

     

    Wednesday, March 09, 2011 10:45 PM
  • Now that you mention it - where have you found the release notes?
    Tore Østergaard
    Oticon A/S, Denmark
    Thursday, March 10, 2011 8:10 AM
  • I managed to find the Visual Studio 2010 SP1 Readme which I guess is the release notes for now: http://go.microsoft.com/fwlink/?LinkId=210711.

    When I fix the link signing issue as described I get another error from Microsoft.CppCommon.targets:
    error MSB4044: The "WriteLinesToFile" task was not given a value for the required parameter "File".

    I am not calling WriteLinesToFile myself so I am a bit puzzled about how to fix this.

     


    Tore Østergaard
    Oticon A/S, Denmark
    Thursday, March 10, 2011 10:14 AM
  • After running mt.exe the manifest is linked together with the switch /DELAYSIGN.

    Therefore the custom buildstep is still needed, but I think it should be better to use /DELAYSIGN:NO.

    Does anyone known where this could changed and why /DELAYSIGN:NO is not used?

    The error is not fixed, because the assemblies build with vs2010 sp1 are still not properly strong named.

     

    Thursday, March 10, 2011 1:50 PM
  • I found the problem!

    The task LinkEmbedManifest is still using the old values <KeyFile> and <DelaySign> and not <LinkKeyFile> and <LinkDelaySign>.

    If they are also specified the custom build step is not longer needed.

    I think this is a bug in Visual Studio 2010 SP1.

    Is there a way to change this?

     

    Thursday, March 10, 2011 2:45 PM
  • My colleague ended up finding the solution that works for both SP1 and SP0. Rather than following the description in the readme file he solved it by setting the key file through AssemblyInfo.cpp:

    [assembly:AssemblyKeyFileAttribute("myKey.snk")]

    ... as described here: http://msdn.microsoft.com/en-us/library/t07a3dye(v=VS.100).aspx


    Tore Østergaard
    Oticon A/S, Denmark
    • Edited by 2re Thursday, March 10, 2011 4:05 PM Added info on which versions it works for.
    • Proposed as answer by Lionfire Tuesday, May 31, 2011 6:32 AM
    Thursday, March 10, 2011 4:04 PM
  • Same MSB4044 error.

    Microsoft C++ team, why are you so quiet?

    Thursday, March 10, 2011 6:33 PM
  • Hi guys,

    we are investigating this case and have news about it asap.

     

     

    Diego Dagum (WinC++ Community PM)

    Thursday, March 10, 2011 7:12 PM
  • Same MSB4044 error.

    Microsoft C++ team, why are you so quiet?


    I just reported the problem to the product group!

    Hope that you get a response soon.


    Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de
    Thursday, March 10, 2011 8:51 PM
    Moderator
  • Hi,

    My name is Amit Mohindra and I’m Program Manager with the MS Visual C++ team.

    We recognize that a change in the assembly signing process in SP1 has introduced an unintentional breaking change and we are sorry for the inconvenience caused by this issue.

    I have detailed the cause and potential workarounds for this issue in the following blog.

    http://blogs.msdn.com/b/vcblog/archive/2011/03/11/10140139.aspx

    Please feel free to contact me at "amitmo(at)microsoft(dot)com" if you have further issues or questions and I will be happy to assist.

    Thanks,

    Amit

    Saturday, March 12, 2011 11:18 PM
  • It is a bug, try to set Embed Manifest = No.

    See also MS Connect:
    https://connect.microsoft.com/VisualStudio/feedback/details/650617/

     

    Wednesday, March 16, 2011 12:36 AM
  • I had the same error after installing SP1, too.

    All I needed to do to get rid of the warning message, was to set Delayed Signing to true, which somehow was not migrated when moving from RTM to SP1. After I changed this signing in the post build step worked like it used to work before.

    Wednesday, March 16, 2011 2:28 PM
  • I followed the instructions as indicated on your blog (patching the SP1 .target file). It works oke (assemblies are signed) for C++/CLR assemblies that have CRL runtime support enabled on the project level (<CLRSupport>true</CLRSupport>).

     

    I have also a large set of C++ project with some C++ /CLR files. On project level CLRSupport is false and only for specific .cpp files CLRSupport is set to true. For these projects delay signing and a custom build seems still be needed to prevent mt.exe : general warning 810100b3.

     

    Is there a workaround these kind of C++ projects?

     

    Sunday, March 20, 2011 10:06 PM
  • Hi,

    Thanks for verifying that the workaround works at the project level. Let me verify about your other question regarding file level settings and I will get back to you.


    Thanks,

    Amit

    Wednesday, March 23, 2011 3:40 AM
  • Hi,

    the workaround works as I now doens't get the error about strong name anymore.

     

    But now I get this error (Project is build with Toolset V90)

    Cannot register assembly "D:\Arbeit64\Projekte\palo_ala_vlado\palo_designer\XlAddin\bin\Release\Jedox.Palo.XlAddin.dll".
    Could not load file or assembly 'Jedox.Palo.Comm, Version=3.2.2.0, Culture=neutral, PublicKeyToken=df062f138958246e' or
    one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A)

    Tuesday, March 29, 2011 2:45 PM
  • Ok,

    this error only happens if you register for COM Interop.

     

    In this case DELAYSIGN must be NO.

     

    Wednesday, March 30, 2011 12:07 PM