Re: Strong Named Key Files - Deployment

From: Brad Simon (bsimon_at_simondeveloping.com)
Date: 07/15/04 

Date: Thu, 15 Jul 2004 05:12:57 -0700

Klaus,

This has shed a lot of light on the subject, and raised a couple more questions, I hope I don't sound too stupid, but what is a container, and how do they work? Feel free to send me a URL for this one.

When you say you MIGHT want to deploy the public key, does that mean you don't HAVE to deploy the public key, or does it mean to deploy the public key IF you don't deply the pair? I would rather only deploy the public key, is that still an SNK? I was under the understanding that you have to at least have the public key, and I think that is what you were saying. I am just trying to clarify, so I can get it right from now on.

I know that some posts fall through the cracks, but it seems that some of my most urgent and difficult posts are ignored, it is just an observation. 

-- 
Thanks,
Brad Simon
 As you mentioned, for standard (non-web) applications the key normally goes
 in the solution directory. That way it is referenced correctly from both
 release and debug builds.
 
 For web projects, I usually create the KP using sn.exe, install it into a
 container in the local CSP and then use the AssemblyKeyName attribute
 instead of a file:
 
   sn.exe -k mywebapp.snk
   sn.exe -i mywebapp.snk mywebapp
 
 Then in your AssemblyInfo file (or wherever you have the assembly
 attributes) instead of doing this:
 
   [assembly: AssemblyKeyFile("..\\..\\mywebapp.snk")]
 
 do this:
 
   [assembly: AssemblyKeyName("mywebapp")]
 
 It's exactly the same thing. To avoid polluting the CSP storage you should
 write down all the keys you install in containers. You can delete them later
 with
 
   sn.exe -d mywebapp
 
 if you need to.
 
 No, but you might want to publish your public key. I don't really know what
 the MSDN docs say on this - what I know comes from reading crypto stuff. And
 besides, I don't use the rinky KPs generated by sn.exe because they're just
 for testing =) But basically,
 
   sn.exe -p mywebapp.snk mywebapp.public.key
 
 will give you the public key in the KP. But generally you DO NOT want to
 ship your KP along with the app.
 
 There are a lot of people trying to help around here but some will
 necessarily fall through the cracks, and sometimes there's simply no one
 around with the specific expertise to give you a ready solution.
 
> -- 
> Klaus H. Probst, MVP
>    http://www.vbbox.com/
> 
> 
>

Relevant Pages

  • Re: Strong Named Key Files - Deployment
    ... in the solution directory. ... container in the local CSP and then use the AssemblyKeyName attribute ... sn.exe -i mywebapp.snk mywebapp ... but you might want to publish your public key. ...
    (microsoft.public.dotnet.distributed_apps)
  • Re: Using the Public Key embedded in the Assembly?
    ... amongst them a keyblob parser. ... well that the keypair I retrieve from the container is not the same as the ... > approach you've been trying to get the private key out of the CSP is not ... >> the digest) with your public key, ...
    (microsoft.public.dotnet.security)
  • Re: Using the Public Key embedded in the Assembly?
    ... assembly and to embed the public key in the assembly. ... When I send the assembly to a customer (together with the license file), ... and no csp container with such name and content exists on the machine of the ... > ImportCspBlob method on RSACryptoServiceProvider, ...
    (microsoft.public.dotnet.security)
  • RE: CryptGetUserKey fails with 8009000d
    ... keyPAIR in the given container. ... temporary keys are NOT saved (once you closed the context handle with ... if you just need to import the public key than you can simple ... > The first problem I had was getting CryptAcquireContext to work on the ...
    (microsoft.public.platformsdk.security)
  • RE: CryptExportKey questions
    ... You normally export a public key wrapped with a SYMMETRIC key (eg. AES ... or generate within the container (eg. ... you would need the handles within the same CSP. ... set hExpKey to NULL. ...
    (microsoft.public.platformsdk.security)