strong naming fails if delay signed

[Guest]

Hi;

I have a solution with 2 projects. 1 project is a windows forms exe and the
other is a dll (all C#). If I set the dll to be delay signed, then even after
I sign it, when the exe runs and first tries to access a class in the dll, I
get an exception saying that the dll failed a strong naming check.

My post-build event in the dll project does a sn -R to strongly name the
dll. So it is always strongly named. It's just that it can subsequently be
obfuscated and then run sn -R again.

When I run sn -vf on the dll, it says it is strongly named.

If I do not delay sign the dll, then it works fine.

Any ideas?

 

[Guest]

Complete error message:
_fusionLog "=== Pre-bind state information ===\r\nLOG:
DisplayName = WriteExpressCore, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=c918efd09163103e\n
(Fully-specified)\r\nLOG: Appbase =
C:\\src\\WriteExpress\\WriteExpress\\bin\\Debug\\\r\n
LOG: Initial PrivatePath = NULL\r\n
Calling assembly : WriteExpress, Version=1.0.1877.15615, Culture=neutral,
PublicKeyToken=7e136062b4e87c91.\r\n
===\n\r\nLOG: Publisher policy file is not found.\r\nLOG: Host
configuration file not found.\r\n
LOG: Using machine configuration file from
c:\\WINNT\\Microsoft.NET\\Framework\\v1.1.4322\\config\\machine.config.\r\n
LOG: Post-policy reference: WriteExpressCore, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=c918efd09163103e\r\n
LOG: Attempting download of new URL
file:///C:/src/WriteExpress/WriteExpress/bin/Debug/WriteExpressCore.DLL.\r\n" string

 

[Steven Cheng[MSFT]]

Hi Dave,

Thanks for your posting. As for the delaysign/Resign problem you mentioned,
I think it is possible that the delaysigned public key is not corresponding
to the privatekey when we resign it. Have you tried testing on some other
assemblies and key pairs. Or would provide the detailes steps when you
generate the key pair, delaysign the assembly , and resigen them with which
key file(with private key info)?
From my local test, the delaysign/resign works correctly without any
problem, so I think the problem is still something with the key pair info.

If any other questions or finding, please feel free to post here.

Thanks & Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Guest]

That's what I thought too. So I did sn -Tp on the assembly each step of the
process - and it was always the same token.

One weird thing though - sn -t on my public key matches the token for sn -T
on the dll. But sn -t on the keypair is a different token.

I just ran "sn -p keypair.snk public.snk" and still the different tokens
between the two files. Is that a problem?

thanks - dave

 

[Nicole Calinoiu]

David,

What you're seeing is the normal, expected behaviour. When running sn -t on
a key file, the file must contain only the public key (as extracted from a
key pair file using sn -p). The documentation on sn.exe does state this,
even if the statement is rather easy to miss.

HTH,
Nicole

 

[Nicole Calinoiu]

Are you sure that the executable is attempting to load the fully signed copy
of the dll? If you don't want to delve into fusion logs to verify this, try
a simple test: ensure that there is no copy of your dll in the GAC, copy the
fully signed dll and the exe into a new directory, then try to run the
beastie.

 

[Steven Cheng[MSFT]]

Hi Dave,

Sn.exe -t can't be used directly against the keypair.snk (which contains
both public, private key). We should generate a file (only contain public
key) through Sn.exe -p , then we can use Sn -t on the generated file.
Otherwise, we'll get the incorrect value. You can view the detailed
description in the MSDN for SN.EXE

http://msdn.microsoft.com/library/en-us/cptools/html/cpgrfstrongnameutilitys
nexe.asp?frame=true

HTH. Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)