强名称签名通过唯一标识、防篡改、支持GAC和并行执行保障程序集安全与兼容，使用AssemblyKeyFileAttribute时需注意路径、权限及CI/CD适配，推荐在csproj中配置并结合延迟签名提升安全性。
.NET的AssemblyKeyFileAttribute类通过在程序集元数据中嵌入密钥文件的路径，为程序集提供了强名称签名。这通常是在项目的
AssemblyInfo.cs
或
AssemblyAttributes.cs`文件中通过一个特性（Attribute）来指定的。简单来说，它告诉编译器去哪里找到那个用于签名的私钥文件。
解决方案
要使用
AssemblyKeyFileAttribute
指定密钥文件，核心步骤是：
生成强名称密钥对： 如果你还没有，需要使用.NET SDK自带的
sn.exe
工具来生成一个强名称密钥对文件（
.snk
文件）。在命令行中运行：
sn.exe -k MyKey.snk
这会在当前目录下生成一个名为
MyKey.snk
的文件。
在项目代码中引用： 打开你的项目中的
AssemblyInfo.cs
（对于较新的SDK风格项目，可能是在
csproj
文件中通过
或直接在代码中通过
AssemblyKeyFileAttribute
）。找到或添加以下一行代码：
using System.Reflection;// ... 其他Assembly属性[assembly: AssemblyKeyFile("MyKey.snk")]// 如果你的.snk文件不在项目根目录，需要提供相对路径// [assembly: AssemblyKeyFile("KeysMyKey.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）机制，就是基于强名称来判断程序集的信任级别的。现在虽然有了新的安全模型，但强名称背后那种“可信来源”的思想，依然渗透在很多地方。
最后，强名称签名还支持并行执行（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属性来配置：
true MyKey.snk
这种方式更简洁，也更符合现代.NET的配置习惯。我个人更倾向于这种方式。
除了直接指定文件，.NET中还有哪些处理强名称签名的替代或辅助方式？
其实除了直接在代码里写
AssemblyKeyFileAttribute
，我们还有不少更灵活或者说更工程化的办法来处理强名称签名，尤其是在自动化构建和团队协作场景下。
通过Visual Studio项目属性页：这是最直观的方式。在Visual Studio中，右键点击项目 -> 属性 -> 签名（Signing）选项卡。在这里你可以勾选“为程序集签名”，然后选择一个现有的强名称密钥文件，或者新建一个。Visual Studio会在幕后帮你处理好
AssemblyKeyFileAttribute
或者相应的MSBuild属性。对于不熟悉代码配置的开发者来说，这是个很友好的入口。
通过MSBuild属性在
.csproj
文件中配置：正如我前面提到的，对于SDK风格的项目，这是我个人更倾向的方式。你可以在
.csproj
文件中直接设置
SignAssembly
为
true
，并通过
AssemblyOriginatorKeyFile
指定密钥文件路径。这种方式的优点是配置集中、版本控制友好，并且方便CI/CD脚本进行自动化处理。
true $(MSBuildProjectDirectory)KeysMyKey.snk
这里我用了
$(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
这个工具是强名称签名的瑞士军刀，对于调试和自动化脚本非常有用。
需要注意的是，这里讨论的是.NET程序集的强名称签名。别把程序集签名和NuGet包签名混为一谈，虽然都叫签名，但目的是不一样的。NuGet包签名是针对包本身的完整性和来源验证，而程序集签名是针对单个DLL或EXE文件的完整性和唯一性。
以上就是.NET的AssemblyKeyFileAttribute类如何指定密钥文件？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1439571.html
微信扫一扫 
支付宝扫一扫 
