.NET的AssemblyKeyFileAttribute类如何指定密钥文件？-C#.Net教程-PHP中文网

强名称签名通过唯一标识、防篡改、支持GAC和并行执行保障程序集安全与兼容，使用AssemblyKeyFileAttribute时需注意路径、权限及CI/CD适配，推荐在csproj中配置并结合延迟签名提升安全性。

.net的assemblykeyfileattribute类如何指定密钥文件？

.NET的AssemblyKeyFileAttribute类通过在程序集元数据中嵌入密钥文件的路径，为程序集提供了强名称签名。这通常是在项目的

登录后复制

AssemblyInfo.cs

或

登录后复制

AssemblyAttributes.cs`文件中通过一个特性（Attribute）来指定的。简单来说，它告诉编译器去哪里找到那个用于签名的私钥文件。

解决方案

要使用

AssemblyKeyFileAttribute

登录后复制

指定密钥文件，核心步骤是：

生成强名称密钥对： 如果你还没有，需要使用.NET SDK自带的
```
sn.exe
```
登录后复制
工具来生成一个强名称密钥对文件（
```
.snk
```
登录后复制
文件）。在命令行中运行：
```
sn.exe -k MyKey.snk
```
登录后复制
这会在当前目录下生成一个名为
```
MyKey.snk
```
登录后复制
的文件。
在项目代码中引用： 打开你的项目中的
```
AssemblyInfo.cs
```
登录后复制
（对于较新的SDK风格项目，可能是在
```
csproj
```
登录后复制
文件中通过
```
<AssemblyOriginatorKeyFile>
```
登录后复制
或直接在代码中通过
```
AssemblyKeyFileAttribute
```
登录后复制
）。找到或添加以下一行代码：
```
using System.Reflection;
// ... 其他Assembly属性

[assembly: AssemblyKeyFile("MyKey.snk")]
// 如果你的.snk文件不在项目根目录，需要提供相对路径
// [assembly: AssemblyKeyFile("Keys\MyKey.snk")]
```
登录后复制
这个路径可以是相对于项目文件（
```
.csproj
```
登录后复制
）的相对路径，也可以是绝对路径。我个人更推荐使用相对路径，这样项目在不同开发环境或构建服务器上移动时，路径问题会少很多。
确保密钥文件可访问： 密钥文件（
```
.snk
```
登录后复制
）需要放置在编译器能够找到的位置。通常，我会把它放在项目根目录，或者创建一个专门的
```
Keys
```
登录后复制
文件夹来存放。在Visual Studio中，你可能需要确保这个文件被包含在项目中，但它的“生成操作”（Build Action）通常设置为“无”（None），因为编译器只是需要读取它，而不是将其编译到程序集内部。

当项目构建时，.NET编译器会读取这个

MyKey.snk

登录后复制

文件，并使用其中的私钥来为生成的程序集进行数字签名。这样，你的程序集就拥有了强名称。

强名称签名在.NET程序集中的核心价值体现在哪里？

我个人觉得，强名称签名这东西，在现代.NET开发里，虽然不像以前那么被强制要求，但它的基础价值是没变的，甚至在某些场景下依然是不可或缺的。

首先，它提供了一个全局唯一的身份标识。两个同名但来自不同源的程序集，如果它们都经过了强名称签名，它们的强名称是唯一的，这就能有效避免命名冲突。这对于大型系统或者共享组件来说，至关重要。你总不希望你的

MyComponent.dll

登录后复制

和别人家的

MyComponent.dll

登录后复制

混淆吧？

其次，强名称签名能够确保程序集的完整性和防篡改。签名过程实际上是生成了一个哈希值，并用私钥加密。当程序集被加载时，运行时会验证这个签名。如果程序集在签名后被修改过，签名验证就会失败，运行时会拒绝加载它。这就像给你的代码盖了个章，证明“这是我发的，没被动过手脚”。这在安全敏感的应用中尤其重要。

再来，它使得程序集可以被安装到全局程序集缓存（GAC）中。如果你有一些需要在多应用之间共享的组件，或者系统级别的库，GAC是个不错的选择。而要进入GAC，强名称签名是硬性要求。

还有一点，虽然现在用得少了，但以前的代码访问安全性（Code Access Security, CAS）机制，就是基于强名称来判断程序集的信任级别的。现在虽然有了新的安全模型，但强名称背后那种“可信来源”的思想，依然渗透在很多地方。

华文笔杆

写材料用华文，华文笔杆帮你搞定公文写作

491

查看详情

最后，强名称签名还支持并行执行（Side-by-Side Execution）。这意味着你可以在同一台机器上，同时安装和运行同一个程序集的不同版本，只要它们有不同的强名称。这对于解决DLL Hell问题，或者在复杂的部署环境中，提供了很大的灵活性。

最头疼的，可能就是你自己的程序集强签名了，结果引用的第三方库没签，那可就麻烦了。强签名的程序集只能引用强签名的程序集，这是一个很强的约束。

指定AssemblyKeyFileAttribute时，有哪些常见的“坑”和注意事项？

说实话，我遇到过不少同事，或者我自己也踩过坑，就是这个

AssemblyKeyFileAttribute

登录后复制

的路径问题和一些相关细节。

相对路径与绝对路径的陷阱：
- 相对路径： 编译器会相对于项目文件（
```
.csproj
```
  登录后复制
  ）来解析这个路径。这通常是最佳实践，因为它使得项目在不同机器上移动时，路径依然有效。但如果你不小心把
```
.snk
```
  登录后复制
  文件放到了一个奇怪的地方，或者项目结构发生了变化，就可能导致编译失败。
- 绝对路径： 虽然可以指定绝对路径，但强烈不推荐。你的同事、构建服务器或者其他环境，很可能没有相同的路径结构，这会直接导致编译错误。我见过有人把
```
C:KeysMyKey.snk
```
  登录后复制
  写进去，然后代码一提交，别人就没法编译了。
密钥文件的存在与访问权限：
- 文件不存在： 这是最常见的错误，编译器找不到
```
MyKey.snk
```
  登录后复制
  文件。检查路径是否正确，文件是否真的在那里。
- 权限问题： 在某些严格的构建环境中，构建用户可能没有读取
```
.snk
```
  登录后复制
  文件的权限。尤其是在CI/CD环境里，本地好好的，一到Jenkins或者Azure DevOps上就报错，那多半是密钥文件路径或者权限的问题。确保构建代理有权访问该文件。
版本控制中的
```
.snk
```
登录后复制
文件： 关于密钥文件要不要进版本控制，这事儿也挺有争议的。
- 如果包含私钥： 理论上，包含私钥的
```
.snk
```
  登录后复制
  文件不应该直接提交到公共版本控制系统，因为它涉及到私钥安全。但对于内部项目，为了方便团队协作和CI/CD，通常会将其提交。在这种情况下，要确保你的版本控制系统是安全的，并且只有授权人员才能访问。
- 如果只包含公钥（延迟签名）： 如果你使用的是延迟签名（
```
AssemblyDelaySignAttribute
```
  登录后复制
  ），那么
```
.snk
```
  登录后复制
  文件只包含公钥，可以安全地提交到版本控制。
构建服务器/CI/CD环境的适配： 这是个大头。本地开发环境可能一切顺利，但到了自动化构建流程中，各种问题就来了。确保：
- ```
.snk
```
  登录后复制
  文件已经存在于构建服务器的正确路径。
- 构建代理（Agent）有足够的权限读取该文件。
- 如果使用了延迟签名，最终的完全签名步骤需要在受控且安全的环境中执行。
与SDK风格项目（.csproj）的交互： 对于新的SDK风格项目，你可能不再需要显式地在
```
AssemblyInfo.cs
```
登录后复制
中写
```
AssemblyKeyFileAttribute
```
登录后复制
。相反，可以在
```
.csproj
```
登录后复制
文件中通过
```
SignAssembly
```
登录后复制
和
```
AssemblyOriginatorKeyFile
```
登录后复制
MSBuild属性来配置：
```
<PropertyGroup>
  <SignAssembly>true</SignAssembly>
  <AssemblyOriginatorKeyFile>MyKey.snk</AssemblyOriginatorKeyFile>
</PropertyGroup>
```
登录后复制
这种方式更简洁，也更符合现代.NET的配置习惯。我个人更倾向于这种方式。

除了直接指定文件，.NET中还有哪些处理强名称签名的替代或辅助方式？

其实除了直接在代码里写

AssemblyKeyFileAttribute

登录后复制

，我们还有不少更灵活或者说更工程化的办法来处理强名称签名，尤其是在自动化构建和团队协作场景下。

通过Visual Studio项目属性页： 这是最直观的方式。在Visual Studio中，右键点击项目 -> 属性 -> 签名（Signing）选项卡。在这里你可以勾选“为程序集签名”，然后选择一个现有的强名称密钥文件，或者新建一个。Visual Studio会在幕后帮你处理好
```
AssemblyKeyFileAttribute
```
登录后复制
或者相应的MSBuild属性。对于不熟悉代码配置的开发者来说，这是个很友好的入口。
通过MSBuild属性在
```
.csproj
```
登录后复制
文件中配置： 正如我前面提到的，对于SDK风格的项目，这是我个人更倾向的方式。你可以在
```
.csproj
```
登录后复制
文件中直接设置
```
SignAssembly
```
登录后复制
为
```
true
```
登录后复制
，并通过
```
AssemblyOriginatorKeyFile
```
登录后复制
指定密钥文件路径。这种方式的优点是配置集中、版本控制友好，并且方便CI/CD脚本进行自动化处理。
```
<PropertyGroup>
  <SignAssembly>true</SignAssembly>
  <AssemblyOriginatorKeyFile>$(MSBuildProjectDirectory)KeysMyKey.snk</AssemblyOriginatorKeyFile>
</PropertyGroup>
```
登录后复制
这里我用了
```
$(MSBuildProjectDirectory)
```
登录后复制
这个MSBuild内置变量，它代表当前项目文件的目录，这样路径解析会更清晰可靠。
延迟签名（Delay Signing）与
```
AssemblyDelaySignAttribute
```
登录后复制
：延迟签名是一个非常巧妙且实用的机制，尤其是在大型团队协作或开源项目中。它的思路是：在开发阶段，程序集只用公钥进行签名（
```
AssemblyDelaySignAttribute(true)
```
登录后复制
），这样开发者无需访问私钥就能编译和测试。等到发布前，再在一个安全的环境中，用私钥进行完整的签名。
```
[assembly: AssemblyDelaySign(true)] // 告诉编译器只用公钥签名
[assembly: AssemblyKeyFile("MyPublicKey.snk")] // 这里MyPublicKey.snk只包含公钥
```
登录后复制
在发布时，你需要用
```
sn.exe
```
登录后复制
工具的
```
-R
```
登录后复制
或
```
-Rc
```
登录后复制
参数对程序集进行重新签名：
```
sn.exe -R MyAssembly.dll MyPrivateKey.snk
```
登录后复制
延迟签名这东西，我觉得挺巧妙的，尤其是在开源项目或者大型团队协作的时候，能解决不少实际问题，避免私钥泄露的风险。
使用
```
sn.exe
```
登录后复制
命令行工具进行辅助操作：
```
sn.exe
```
登录后复制
（Strong Name Utility）不仅仅用于生成密钥对，它还可以用于：
- 查看程序集的公钥或公钥令牌：
```
sn.exe -Tp MyAssembly.dll
```
  登录后复制
- 验证程序集的强名称：
```
sn.exe -Vf MyAssembly.dll
```
  登录后复制
- 重新签名延迟签名的程序集：
```
sn.exe -R MyAssembly.dll MyPrivateKey.snk
```
  登录后复制
  这个工具是强名称签名的瑞士军刀，对于调试和自动化脚本非常有用。