Strongly Frustrated

I'm going to pose a few questions to the community. I'd like you to comment on your experiences after answering these questions:

  1. How many of you know what a Strong Name Key is?
  2. How many of you know how to get one?
  3. How many of you know how to use it once you have it?
  4. How do you feel about the whole “strong name“ process?

Strong-name keys have very much been the focus of my attention over the last two weeks. Before I talk about it further, I'd like to hear some other people's experiences with it. I have a feeling it's a silent source of frustration for many. Tell me about it.

9 Comments

  • I don't know why using Strong Names is not supported from the IDE.

    I think that is very frustrating not having an easy interface to deal with the entire process.

  • 1. no

    2. no

    3. no

    4. Embarrassed :(

  • 1. Yes - I think

    2. Yes

    3. Yes, but I haven't looked into the real differences between "test" keys from sn.exe and "real" ones which cost money

    4. I think that delay-signing looks something that was added as an after-thought, but is a definite improvement over the even fiddlier process of signing COM components for download that I previously had to use.

    There also seems to be some overloading of the strong name mechanism in that sometimes its use just to get things in the GAC, whilst others it's to get some real sense of security. When it's the latter, the danger of making the process to simple is that people will not think hard enough about what is a very difficult issue.

    My most recent thoughts have been how to handle strong names in open source development. My current thought is again to go with delay signing, and making the public component of the key available via whatever source control system is in use.

  • 1. yes

    2. yes

    3. i guess so

    4. i don't think anything. i guess it takes some work to get one. I've never used one personally, I just read about them because of my MCAD. :)

  • 1) yes

    2) yes

    3) yes

    4) it's not implemented right. sn has a flag, -Vr, which registers an assembly so it will be skipped for signature checking, which means anyone can tamper with the signature. Signatures can also easily be removed from a signed assembly using ILAsm/ILDasm. This is to me the weak spot in this whole matter: when I have an exe (signed) and I want it to use only signed assemblies, signed by me, any person can alter that behaviour. That shouldn't be possible.

  • 1.) Yes

    2.) Yes

    3.) Yes

    4.) Once you automate it, it isn't that big of a deal. We have a build process that does it all for us, so we delay sign it, obfuscate it, and then sign it once that is done.



    I have never looked at any way to get a key other than to generate my own with sn.exe (like buying one), so I can't comment on that. It would be nice if the IDE had more support, but MSDN was (surprisingly) good with it's content about sn.exe and the different methods to sign assemblies.

  • Thanks Bruce Krautbauer for the link- seems to teach me some thing i did not know :)

  • Something I've noticed recently is the HUGE delay with VB.Net when using strong-name keys. To do the error underlining VB.Net recompiles your application in the background to determine where the errors are, if your application has a strong name this will freeze the IDE for a number of seconds, very annoying while typing. A fix is to put a #If RELEASE around the strong name attribute, i'm not sure if delayed signing is quicker, that may be a solution too.



    I'm also annoyed by free 3rd party components that don't have a strong name, usually rendering them useless.

  • 1) Yes

    2) Yes

    3) Yes

    4) Seems ok to me: Make a key, use it to sign an assembly. I was already very familiar with public key signing and tools like PGP, so it seemed perfectly natural to me.



    I can only answer Yes to these questions as of two days ago when Andy Smith taught me that I needed a strongly-named assembly so I could assign it Full Trust with the CAS tool to execute unmanaged code.



    Too bad the stupid COM object still didn't work!

Comments have been disabled for this content.