strong naming fails if delay signed

20 Feb 2005 4:01 PM

David Thielen

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?

--
thanks - dave

20 Feb 2005 4:03 PM

David Thielen

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

21 Feb 2005 3:44 AM

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.)

21 Feb 2005 4:35 AM

David Thielen

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

Show quoteHide quote

"Steven Cheng[MSFT]" wrote:

> 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.)
>
>

21 Feb 2005 6:55 PM

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

Show quoteHide quote

"David Thielen" <thielen@nospam.nospam> wrote in message
news:9A1A728C-0761-454D-B5E4-0E7E0D028A6F@microsoft.com...
> 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
>
>
> "Steven Cheng[MSFT]" wrote:
>
>> 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.)
>>
>>

22 Feb 2005 3:00 AM

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.)

21 Feb 2005 6:59 PM

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.

Show quoteHide quote

"David Thielen" <thielen@nospam.nospam> wrote in message
news:6196E956-B5EB-4025-ABF5-C554EC6A25BA@microsoft.com...
> 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?
>
> --
> thanks - dave