C # assembly uses strong name (strong name) signature/Strong name signature

a Strong name signature method:

Strong signature:

1. A strong signed DLL can be registered with the GAC, and different applications can share the same DLL.

2. A strongly signed library, or an application can only reference a strongly signed DLL, cannot reference a DLL that is not strongly signed, but a DLL that is not strongly signed can reference a strongly signed DLL.

3. Strong signatures cannot protect the source code, and strong-signed DLLs can be recompiled.

4. Strong-Signed DLLs can prevent malicious tampering by third parties.

Strong Signature Method:

1. Active Code:

1.1 Use the VS tool command:snk–k mykey.snk to generate the signing public key.

1.2 Add the public key to the project, set the project properties, set the signing public key

1.3 Rebuild the project.

2. No source code.

2.1 Create strong signature key:

Sn.exe-k key.snk

2.2 Disassembly DLLs for IL

ILDASM.exe somelibrary.dll/output=somelibrary.il

The directive will disassemble the DLL and generate somelibrary.il if the DLL contains embedded resource,

The Somelibrary.res file is generated and the corresponding embedded resource file is generated.

2.3 Reassembly to DLL

ILASM.exe somelibrary.il/dll/output=somelibrary.dll/key=key.snk

If you have an embedded resource file, you need to add/resource=somelibrary.res

The difference between a strongly signed DLL and a non-signed post-compilation:

Unsigned:

Strong-Signed:

For more details refer to stringnaming

Http://windowsdevcenter.com/pub/a/dotnet/2003/04/28/strongnaming.html

Category: C#/net
1. Open the Visual Studio 2008 Command Prompt command-line tool.

2. Generate a public/private Key Pair file with Sn.exe: Sn-k test.snk. If you do not specify a size, its size is 596 bytes (publickey,32 publickey Header, 436 privatekey).

3. Add [Assembly:assemblykeyfile (@ "Test.snk")] to the AssemblyInfo.cs of the program, or you can specify it in Build option (/KEYFILE:TEST.SNK). Regenerate the Test.dll. In VisualStudio you can also specify with the project properties.

4. Sn-v Test.dll Check test.dll is not already a strongname program, output: Test.dll is valid. Indicates the successful generation of a program with PublicKey sn-t Test.dll can get this assembly Publickkeytoken.



Why use strong name signing:

By signing a strong-named assembly, you can ensure that the name is globally unique. Strong names also specifically meet the following requirements:

A strong name relies on a unique key pair to ensure the uniqueness of the name. No one will generate the same assembly name that you generated, because the name of the assembly generated with one private key is not the same as the name of the assembly generated with the other private key.
A strong name protects the version lineage of the assembly. A strong name ensures that no one can build subsequent versions of your assembly. Users can be confident that the version of the assembly they are loading comes from the same publisher who created the version (the application was built with that version).
Strong names provide a reliable integrity check. After a security check with the. NET framework, you can be confident that the contents of the assembly have not been changed since it was built. Note, however, that strong names or strong names themselves do not imply a level of trust, such as those provided by digital signatures and support certificates.
When you reference a strong-named assembly, you should be able to benefit from it, such as version control and named protection. If this strong-named assembly later references an assembly with a simple name (which does not have these benefits), you will lose the benefit of using a strong-named assembly and will still generate DLL conflicts.  Therefore, a strong-named assembly can only refer to other strong-named assemblies. Gac

I. Role of the GAC

The full name of the global Assembly cache is the ability to store some common Assembly that are used by many programs, such as System.Data, System.Windows.Forms, and so on. In this way, many programs can get assembly from the GAC without having to copy all the assembly that are needed to the application's execution directory. For example, if there is no GAC, it is bound to be in the directory of every WinForm program from C:\WINDOWS\Microsoft.NET\Framework\ A copy of the System.Windows.Forms.dll under VX is clearly not as easy to get from the GAC as it is for assembly upgrades and version control.

Ii. strong naming of assemblies

Because different companies might develop assemblies with the same name, if the assemblies are copied to the same directory, the last installed assembly will replace the previous assembly. This is why the famous windows "DLL Hell" appears.

Obviously, it is not enough to differentiate an assembly with a file name, and the CLR needs to support a mechanism to uniquely identify an assembly. This is called a strong-named assembly.

A strong-named assembly contains four unique flags for the assembly's attributes: file name (without extension), version number, language culture information (if any), public key.

This information is stored in the assembly's manifest (manifest). The manifest contains the assembly's metadata and is embedded in a file in the assembly.

The following string identifies four different assembly files:

"MyType, version=1.0.1.0,

Culture=neutral, publickeytoken=bf5779af662fc055 "

"MyType, version=1.0.1.0,

Culture=en-us, publickeytoken=bf5779af662fc055 "

"MyType, version=1.0.2.0,

Culture=neturl, publickeytoken=bf5779af662fc055 "

"MyType, version=1.0.2.0,

Culture=neutral, publickeytoken=dbe4120289f9fd8a "

If a company wants to uniquely identify its assembly, it must first obtain a public/private key pair, and then associate the shared secret key with the assembly. There are no two companies with the same public/private key pair, it is this distinction that allows us to create assemblies with the same name, version, and language culture information without causing any conflicts.

The strong-named assembly corresponds to the so-called weakly named assembly. (In fact, it is an ordinary assembly that is not strongly named). The two assemblies are structurally identical. All use the same PE file format, PE header, CLR header, metadata, and manifest (manifest). The real difference between the two is that a strong-named assembly has a public/private key pair signature for the publisher, where the public/private key pair uniquely identifies the publisher of the Assembly. With a public/private key pair, we can uniquely identify the assembly, enforce the security policy, and the versioning policy, the ability to uniquely identify the assembly so that when an application tries to bind a strong-named assembly, the CLR can implement certain "known security" policies (such as trusting only a company's assemblies).

Iii. How to create a strong-named assembly, how to view the PublicKeyToken of a strong-named assembly

How to create a strong-named assembly

===================

1. In Visual Studio, right-click on the Class Library project and select Properties.

2. Select the Signing tab on the left.

3. Tick the Sign the Assembly check box. Select <new...> in the drop-down list;.

4. Give the SNK file a name in the popup dialog box. Press ok.

5. Strong naming of the assembly is complete.

How to view the public key token for a strong-named assembly

=========================

Sometimes you need to refer to your written strong-named assembly in the Web. config file or somewhere else, and you need to write fully qualified name like this:

mynamespace.myassembly, version=1.0.3300.0, Culture=neutral, publickeytoken=b77a5c561934e089

The first three sections are relatively easy to get, because you wrote it yourself, and of course you know assembly's name, version, and culture information. The tricky part is how to get the public key token of the assembly that you signed. A common approach is to use reflector to open your own assemblies and then get tokens (in fact, Reflector will give you complete information as in the example above). But it still seems a bit overkill. If you've already opened Visual Studio, wouldn't it be better to just point a menu item in the VS menu to get the answer? Here is the step.

1. In Visual Studio, open the Tools menu and click the External Tools menu item.

2. In the External Tools dialog box that pops up, click the Add button.

3. Follow the configuration. Sn.exe This tool is in a different folder under different versions of VS. the simplest way to find it is to enter "where Sn.exe" in the VS Command prompt. Write "-T $ (TargetPath)" in the Parameters box. Then tick "Use Output window". In this case, the result will be the output window of vs. Then click OK,

4. Results.

5. You can see the results in the Output window. This works well when you have more than one project in your solution. Just click on project in the Solution Explorer and click on our menu item to do it.

Iv. How to register your DLL in the GAC

In development and testing, the most common tool is GACUtil.exe. registering assemblies in the GAC is similar to COM registration , but relatively easier:
1. Add an assembly to the GAC : gacutil/i sample.dll (Parameter/I is the installation meaning)
2. Move the assembly out of the GAC gacutil/u sample.dll (Parameter/u removes the meaning)
Note: You cannot install a weak-named assembly into the GAC .
If you try to add a weak named assembly to the GAC , you receive an error message: "
Failure adding assembly to the Cache:attempt-install an assembly without a strong name "
d) Private deployment of strong-Named assemblies

Example:

C:\Program Files\Microsoft Visual Studio 8\vc>gacutil-i F:\myweb\BalloonShop\Cl
Asslibrary1\bin\debug\classlibrary1.dll

In C:\WINDOWS\assembly will see ClassLibrary1, registered successfully

V. View the contents of the GAC file and copy the DLL

In the project we often introduce third-party DLLs, in general we can copy the required DLL files to a place on the hard disk, and then add references in the project, this operation is very simple! But sometimes we come across a situation where the DLL we're referencing is in the GAC of the target machine, and we can't copy it manually.

In fact, the GAC of Windows has a corresponding directory, generally c:\Windows\assembly\, this directory has some special, it is stored in the native installed and registered library DLL, and does not allow the user directly to the elements of the relevant operations (such as copy, Cut, Paste, modify name, etc.), but you can directly drag and drop DLL files from another location directly into this directory for DLL installation, but we can not directly copy the DLLs that have already been installed. Here I'll show you a way to do this.

First we switch to the command-line mode of Windows, start-run-cmd-carriage return, then go to the GAC's directory and use the dir command to see what's in it, such as.

It seems that the directory structure in the GAC can be understood, and basically we can differentiate the Dir type according to the Processor architecture column in the GAC directory. For example, the System.Web.Extensions we are looking for is MSIL, and in cmd mode it should correspond to Gac_msil, then switch to this directory and dir.

See the System.Web.Extensions Assembly we're looking for, it's also a dir, continue to cut in and Dir.

At this time there is only one directory, continue to cut in, and then dir can see the DLL file we eventually want, and then copy it by copying it out on the OK!

Tip: When using commands in CMD mode, if the file name or directory name you want to enter is too long, you can first tap some characters and then auto-complete with the TAB key, and the Windows command tool will automatically find the matching content for you!

Vi. examples

As shown, 2 new class library files were created: ClassLibrary1, ClassLibrary2

1, using the 3rd above to create a strongly typed assembly ClassLibrary1, and registered in the GAC (you can use the above 3rd method, you can also use the anti-compiler to decompile, you can view the PublicKeyToken value.) ClassLibrary2 is null,classlibrary1 for 568e03e6162a7a2e).

2, in the DataAccess reference ClassLibrary1, ClassLibrary2, compile DataAccess.

3, into the DataAccess Project Bin\Debug folder, only ClassLibrary2.dll and DataAccess.dll (no ClassLibrary1.dll)

It is shown that the program obtains ClassLibrary1.dll directly from the GAC instead of referencing the ClassLibrary1.dll copy to its own debug from the ClassLibrary1 project.

C # assembly uses strong name (strong name) signature/Strong name signature