none
why does strong name validation only sometimes fail if AssemblyDelaySign(true) is missing for a mixed-mode assembly? RRS feed

  • Question

  • I recently discovered a rather odd behavior in .Net 4 concerning delay-signed assemblies.

    The setup is as follows:

    - foo.exe is a native win32 app which uses bar.dll

    - bar.dll is a mixed-mode assembly containing native and managed code (.Net 4), it is signed with sn.exe, but it has no AssemblyDelaySign attribute

     

    Now on most installations, we haven't had a problem with this. You launch foo.exe, it loads bar.dll and runs just fine.

    On some, however, it does not and you get an error like this for bar.dll:

    Exception type:   System.IO.FileLoadException

    Message:          Could not load file or assembly 'bar, Version=some.version.number, Culture=neutral, PublicKeyToken=whatever' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A)

    InnerException:   System.Security.SecurityException

    This can be avoided by setting [assembly:AssemblyDelaySign(true)]; in bar.dll, but I would still like to know why it still works most of the time even without that attribute.

    Was there maybe an update to .Net 4 that caused a change in behavior as to whether or not that attribute is required?

    Or is there some way to configure .Net 4 to behave one way or the other?

     

    Wednesday, July 20, 2011 7:33 AM

All replies

  • Hi,

     

    Thank you for your question, we're doing research on this case, it might take some time before we get back to you.


    Eric Yang [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Thursday, July 21, 2011 7:46 AM
  • 1.  Is this only happening on machines running .Net 4 or machines with VS/SDK installed?  Try an appconfig file targeting a different version of the framework on the affected machine with this and see if it repros
    2. Is the application deployed locally or remotely, network share?
    It sounds like the mixed-mode dll is not fully trusted on the machine it's ran on and delay signing it just skips the security verification piece.  You can use caspol.exe to set trust level on machines with VS or SDK installed:
    Caspol.exe (Code Access Security Policy Tool)
    http://msdn.microsoft.com/en-us/library/cb6t8dtz(v=VS.100).aspx
    You can try setting back to legacy policy pre- .Net 4
    <NetFx40_LegacySecurityPolicy> Element
    http://msdn.microsoft.com/en-us/library/dd409253.aspx
     
    More info:
    Security Changes in the .NET Framework 4
    http://msdn.microsoft.com/en-us/library/dd233103.aspx
    If this does not resolve it, and you cannot determine your answer here or on your own, consider opening a support case with us. Visit this link to see the various support options that are available to better meet your needs:  http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone.

    --Trevor H.
    Send files to Hotmail.com: "MS_TREVORH"
    Thursday, July 21, 2011 4:40 PM
    Moderator
  • The application is deployed locally on the system drive.

    We have had one report where it fails Windows XP SP3 without VS 2010 installed, but the best way to reproduce it was to install our application (which installs .Net 4 client framework as prerequisite, among other things) first, then install VS 2010 Ultimate.

    Before VS 2010 was installed it would run, afterwards it would fail.

    On machines which already had VS 2010 Ultimate installed (and thus the full .Net 4 development environment), installing our application afterwards did not cause the issue.

     

    Friday, July 22, 2011 6:30 AM