Visual Studio is not easy to use when signing an assembly

Because our project uses a context data management framework implemented by LogicalCallContext at the underlying layer, all Unit tests cannot run normally. Specific phenomena have been described in detail in "serious problems of LogicalCallContext only in UnitTest and WebHost. The solution is to perform strong signatures on the relevant Assembly and add it to GAC. Unit Test can recognize the type of LogicalCallContext-based project. With the powerful IDE Visual Studio, the Assembly signature is well implemented-you only need to specify a Key File in the Signing Tab of the Properties object box of the Project. However, Visual Studio is not doing well.

1. Visual Studio automatically copies a Key File in the project root directory.

For example, assume that a solution has two projects: Lib1 and Lib2. Now we need to use"Same Key File"Sign Lib1 and Lib2. The directory structure corresponding to Lib1, Lib2, and Key File (Key. snk) is shown in the right figure: Key. snk and Lib1 and Lib2 are under the same directory.

Right-click the Lib1 project file, select the Properties menu item, and select the Signing Tab to set the Assembly signature. Select the Sign the assembly check box, select the <Browse> option in the drop-down box, and in the pop-up File selection dialog box, choose Key File: Key. snk.

However, when you select the Key. snk file,Visual Studio does not use this File as the Key File signed for this Assembly. Instead, it automatically copies the File to the root directory of Lib1.. What is used for assembly signature is not the desired File Key, but the copy of the File Key (as shown in the right figure ).

I don't quite understand how Microsoft considers such a design, but I cannot accept it for our current project. In the above example, there are only two projects that need to be signed, so we need to maintain two Key files. However, there are dozens of projects in our project, which means that we need to maintain dozens of different Key files, from the maintenance perspective, if I need to replace another Key File one day, I need to update each project.

Is there any way for all projects to use the same Key File for signature? Of course, otherwise I will not write this article. In general, we have three different solutions.

Solution 1: Use the AssemblyKeyFileAttribute feature to specify the Key File

The AssemblyKeyFileAttribute feature is defined in the System. Reflection namespace and is used to specify the Key File used for strong signature of the project. Therefore, you only need to specify the Key File path in AssemblyInfo. cs (or elsewhere. The following code specifies the Key File that I really want to sign for the Lib1 project.

   1: [assembly: AssemblyVersion("1.0.0.0")]

   2: [assembly: AssemblyFileVersion("1.0.0.0")]

   3: [assembly: AssemblyKeyFile("..\\Key.snk")]

However, this is not a recommended Key File method. When you add the AssemblyKeyFileAttribute feature, Visual Studio displays the following warning:"Use command line option '/keyfile' or appropriate project settings instead of 'assemblykeyfile'". The following two solutions are recommended: command line or project settings.

Solution 2:Use the command line for strong Signature

I believe that you will not be unfamiliar with the method of strong signature of the Assembly through the command line. In this way, you can directly use the. NET Framework tool (SN.exe: Strong Name Tool ). For more information about sn.exe parameter settings, see the MSDN online documentation (http://msdn.microsoft.com/en-us/library/k5b5tt23 (VS.80). aspx.

Solution 3: Add Key File in Link mode

This was my first thought, but when I tried to add the Key File to the Properties subdirectory of the project File, it re-created the new File. However, some people commented that this method is feasible. After all I tried it, I just needed to add the Key File to the root directory of the project in Link mode.

Solution 4:Or through Project Setting)

In the beginning of the article, you can directly set the project's Signing attributes. Some people will say, aren't you saying that this method will lead to Key File replication? Why are you still using this method. To solve this problem, we need to change our thinking: all the settings of the project through the project setting object box will be reflected in the project file (. csproj or. vbproj ). Although Visual Studio cannot achieve our goal, what if we update the project file directly? Practice has proved that this solution is feasible. To this end, we open the Lib1 project File Lib1.csproj through NotePad, add the <AssemblyOriginatorKeyFile> element to the <ProjectGroup> element, and specify the Key File path (.. \ Key. snk.

   1: <?xml version="1.0" encoding="utf-8"?>

   2: <Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

   3:   ......

   4:   <PropertyGroup>

   5:     <SignAssembly>true</SignAssembly>

   6:   </PropertyGroup>

   7:   <PropertyGroup>

   8:     <AssemblyOriginatorKeyFile>..\Key.snk</AssemblyOriginatorKeyFile>

   9:   </PropertyGroup>  

  10: </Project>

Author: Artech

Source: http://artech.cnblogs.com

The copyright of this article is shared by the author and the blog Park. You are welcome to repost this article. However, you must retain this statement without the author's consent and provide a clear link to the original article on the article page. Otherwise, you will be held legally liable.