Join Ted Neward for an in-depth discussion in this video Demo: Strong name, part of CLR Assemblies Deployment for .NET Developers.
- [Instructor] So first of all, from within a command prompt, just to make sure that all the tools and everything are working, just go ahead and type SN from the command line. Now it's going to generate a whole slew of help texts, describing how to use this thing. And many of these options are going to seem very arcane because, well, A. Command line tool, and B. Because Microsoft was really in a mode where they liked single-letter flags here. The one that we are looking for is the one that will actually create a public key, private key pair.
As you can see here, we can identify, we can set or reset, delete, compute, et cetera. And in particular, the one we want to use is to create the strong name. Here, that goes by the incredibly intuitive parameter of dash K. Generate a new key pair of the specified size, and write it into out file. So we're going to do an SN dash K, and we're going to just call this Ted. And by loose convention, we will put this into a file with an extension of SNK for strong name key pair.
You can call it whatever you'd like. The only place this file will ever be referenced is from within your code, but most of the demos and so forth that you'll see out there on the internet will use SNK as an extension. When we are done, we have here a file called ted.snk. Now I generated this inside of the hello world project. Typically, these files are going to be things that you will want to have in a little bit more global fashion. So I'm going to move that to the root of my project. So that here, we see it referenced from both hello world and people.
Now, having generated that particular file, I can now go into people and in particular, I can specify using another one of these assembly attributes that I want this to be strongly named. So I can use the assembly key file attribute, and here, I can specify the name of the assembly key file. That is to say ted.snk. This is relative to the project directory, so, going back real quick to the command line here, this is actually in the directory that's the parent to people, which is the project directory.
So here, this would be a dot and because there's a backslash there, we'll do the name space escaping, ted.snk. Now, assuming that all of that works, if we do a build here, now, the resulting output from people will be a little bit different. So now, if we go look inside of the people assembly, when we look in the manifest, it'll start very much the same. We can see the assembly directive here, we can see the various attributes that we've specified.
Right? As a matter of fact, we can see the key file attribute. And again, notice that this string is actually represented in its ask key format. But more importantly, down below, we see a new directive here. Public key and this, in fact, contains the contents of the public key. Now, you don't really need to have a deep knowledge of public key, private key cryptography to understand all of this, so I'm going to pass over what exactly a public key is. Other than to say this is simply something that anybody can use to verify that this came from us, from me.
Specifically, from that particular SNK file. The public key for people is embedded inside of the assembly, but something else has changed, as well. When we go look at hello world again, if we go back to hello world, and if we go look inside of this directory here, when we look at the hello world manifest, now notice that, again, like mscorlib, people now also has a public key token element, as well.
This is that shortened version of the key that I was referring to earlier. This is effectively, as simply a shortcut way to verify that we are, in fact, referencing the correct version of people. And if somebody were to, in fact, try to temper with the assembly, the CLR would be able to verify that. As a matter of fact, let's try that.
- Reviewing the concept of assemblies
- Reviewing library assemblies in ildasm
- Working with assemblies and modules
- Working with assembly scope types
- Reviewing assembly names and versions
- Referencing assemblies from managed code