Re: compiler error while trying to strong name a dll

From: Huihong (huisinro_at_stanfordalumni.org)
Date: 09/11/03 

Date: Wed, 10 Sep 2003 17:23:10 -0700

It is probally that your DLL is not marked as strong
named, or you are using a different .snk file than the
original key file the DLL was first signed. Make sure the
key file is in the right location.

In order to sign a DLL, its Strong Name Signature field
in the CLR header must have 128 bytes space reserved. You
can use our .NET Explorer to examine your file,

http://www.remotesoft.com/dotexplorer

click MetaData view, click CLR Header, if you see Strong
Name Signature is 0, then you can not sign the file.

Did you add the correct attributes to your assembly?
following is the steps,

1) create the strong name key using the SN utility:
sn -k sample.snk

(2) compile your assembly with the key by adding a
declaration to the assembly to indicate the location of
the key file, as shown below,

[assembly: AssemblyDelaySign(false)]
[assembly: AssemblyKeyFile("sample.snk")]
class StrongNameTest
{
  ...
}

Here is some more info,

http://www.remotesoft.com/salamander/obfuscator/manual/#si
gnature

You have to put those attributes in your source code
before you can sign the assembly with strong name. The
assembly must be re-signed with the same key file, in
other words, you can not sign other people's assemblies.

Hope this is useful,

Huihong
The most complete code protection tools
http://www.remotesoft.com

>-----Original Message-----
>Hi:
>
>I've bee trying for the past days to strong name a .dll
>using a public - private key pair and I get the
following
>compiler error
>
>Cryptographic failure while signing
>assembly 'assemblyName.dll' -- 'Access denied. '
>
>I looked up the error in the .NET Framework
documentation
>and here's what I found
>
>Compiler error CS1548
>Cryptographic failure while signing assembly 'assembly' -
> 'reason'
>A failure occurred in a cryptographic function. This
>indicates a problem with the operating system
>installation.
>
>Looking a little further I found an article that talked
>about solving the problem when 'reason' was "'Error
>reading key file 'key.snk' -- The system cannot find the
>file specified", but it doesn't say a thing
about 'Access
>denied'.
>
>The funny thing is that I can both create a public-
>private key pair using sn -k tool and strong name an
>assembly using such a key pair when I'm logged as
>administrator, but I can't do neither of those two
things
>whe I'm logged as a normal user. But funnier still is
the
>fact that this only happens at work, because at home I
>can both generate the key and strong name the assembly
>whether I'm logged as administrator or not.
>
>So, here's what I think is happenning. I know for a fact
>that Windows XP default installation is different
>deppending on whether the computer is connected to a LAN
>(or intranet or whatever)or not, and since the computer
>at home is not connected and the one at work is, and
>considering the fact that the documentation says that
the
>error is caused by a problem with the operating system,
I
>think that there's some option (maybe some permission or
>something) somewhere that allows normal users to
generate
>keys and strong name assemblies and that this option is
>disabled by default in the computer at work and is not
>disabled in the computer at home, because the first one
>was installed while connected and the second one while
>disconnected.
>
>The problem is tha if I'm right I can't find any option
>(or permission or whatever) that allows normal users to
>generate keys and strong name assemblies, and if I'm
>wrong I need to know how to solve the problem, because I
>can't have everyone with administration priveleges
>running around just to strong name an assemblie.
>
>So, any help will be grately appreciated.
>
>Thanks, Amanda
>
>
>.
>

Relevant Pages

  • Re: Sharing Code
    ... But this is a red-herring you've thrown in and really has nothing to do with the general precept and good practice of signing any assembly you create because it is *the easiest thing to do* when creating the most flexible of assemblies. ... How are you making it sound oh so time consuming to add a reference to a key file when you know damn well it takes seconds, which in any normal developer's book is zero-effort. ... in order to avoid warnings I moved the signing from AssemblyInfo to the properties pane. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Best ways to manage strongname keys/key files?
    ... We use the same key pair for all projects. ... assemblies (not with BizTalk), we played for a while with delay signing, ... using relative paths to a common key file ...
    (microsoft.public.biztalk.general)
  • Re: compiler error while trying to strong name a dll
    ... why can I strong-name the .dll while ... I'm logged as administrator and then when I'm not logged ... >original key file the DLL was first signed. ... you can not sign other people's assemblies. ...
    (microsoft.public.dotnet.security)
  • Re: Sharing Code
    ... You seem to assume I don't know how VS works with key files, yet I'm the one who has been signing all of his assemblies for seven years now. ... If you don't want it to copy the file like that (and this is nothing specific to the key file, all the files work this way in VS) then you first must make a link to your key file from within your project. ... I've run into the problem where a production assembly being signed means that a unit test assembly needs to be signed too, if you want to use InternalsVisibleTo. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: .NET dll config file
    ... > application has some other .NET dll references. ... assemblies to a separate folder you create problems because you have to tell ... So if your library is called by a "third party application" ... You cannot create a config file just for your DLL. ...
    (microsoft.public.dotnet.framework)
Quantcast