C# 找不到 sn.exe 来签署程序集
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1535871/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Cannot find sn.exe to sign Assembly
提问by programmernovice
I looked into C:\Program Files\Microsoft.NETand I can't see any SN.exefile.
我看了看C:\Program Files\Microsoft.NET，我看不到任何SN.exe文件。
I have .NET 3.5 runtime installed; isn't that enough ?
我安装了 .NET 3.5 运行时；这还不够吗？
采纳答案by Cam Soper
You need to install the Windows SDK 6.0a, not just the runtime.
您需要安装 Windows SDK 6.0a，而不仅仅是运行时。
If you've installed VS2008, you'll find it's already installed, and sn.exe will be here:
如果你已经安装了VS2008，你会发现它已经安装好了，并且sn.exe会在这里：
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\sn.exe
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\sn.exe
Otherwise, if you don't have VS2008 installed, you can download the SDK individually here.
否则，如果你没有安装 VS2008，你可以在这里单独下载 SDK 。
The file sn.exe is not available in the SDK. The current version of the SDK is 6.1, perhaps they removed sn.exe in this release.
文件 sn.exe 在 SDK 中不可用。SDK 的当前版本是 6.1，也许他们在此版本中删除了 sn.exe。
回答by psychotik
It's part of the SDK (.NET, or now the Windows SDK)
它是 SDK（.NET，或现在的Windows SDK）的一部分
回答by leppie
Nope, looks like you need the SDK for that :(
不，看起来您需要为此使用 SDK :(
FYI, the Runtime itself would not be under C:\Program Files\Microsoft.NET-- all it's files live [only] under C:\Windows\Microsoft.NET\vXXXXXX\
仅供参考，运行时本身不会在C:\Program Files\Microsoft.NET- 它的所有文件[仅]在C:\Windows\Microsoft.NET\vXXXXXX\
回答by Icarus
- open command prompt
- type
cd \ - type
dir /s sn.exe you will get output something like
Volume in drive C has no label.Volume Serial Number is XXXX-XXXX.
- 打开命令提示符
- 类型
cd \ - 类型
dir /s sn.exe 你会得到类似的输出
Volume in drive C has no label.Volume Serial Number is XXXX-XXXX.
Directory of C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin
目录 C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin
11/07/2007 12:01 PM 95,728 sn.exe
1 File(s) 95,728 bytes
You found the directory :)
if not, there is no sn.exein your system. Install SDK then.
您找到了目录 :)
如果没有，则sn.exe您的系统中没有。然后安装SDK。
回答by Ruben Bartelink
I'm sure you have your reasons -- and there are definitely plenty cases where SN.exeis unavoidable and/or appropriate (Delay Signing for one). (And I've +1'd the Q and the Accepted A and am not disputing their merit in any way so please disregard this if it doesn't apply in your case)
我相信你有你的理由——而且肯定有很多情况SN.exe是不可避免的和/或适当的（延迟签名）。（并且我已经对 Q 和接受的 A 进行了 +1，并且不会以任何方式质疑它们的优点，因此如果它不适用于您的情况，请忽略这一点）
Note that SN.exeis rarely needed in practice - the wiring in Microft.<lang>.targetsthat drive the compilers [and AL.exeetc.] all [effectively] take the SignAssemblyflag in the .proj file into account and conditionally pass in the key to the compiler(s) etc. so it can do all the work in a single touch of the assembly inline (mainly for perf reasons).
请注意，SN.exe在实践中很少需要 -Microft.<lang>.targets驱动编译器 [AL.exe等] 中的接线[有效地]SignAssembly将 .proj 文件中的标志考虑在内，并有条件地将密钥传递给编译器等，因此它可以在一次内联汇编中完成所有工作（主要是出于性能原因）。
This logic also deals with the distinction between .snkand .pfxkeys (which are password protected and get secreted into a Key Container). Depending on which form, there is then either a KeyContainerNameor KeyOriginatorFileproperty resolved by Microsoft.Common.targetsin the Runtime directory - Search for ResolveKeySource.
此逻辑还处理.snk和.pfx密钥之间的区别（受密码保护并被隐藏到密钥容器中）。根据哪种形式，然后在运行时目录中解析KeyContainerName或KeyOriginatorFile属性Microsoft.Common.targets- 搜索ResolveKeySource.
If the reason you need to do a SNis because you've just rewritten an assembly, the same pattern should generally hold, i.e. Mono.Ceciland tools a la PostSharp (I assume, not confirmed) generally also take the same arguments and/or can be made to do the signing inline.
如果您需要执行 a 的原因SN是因为您刚刚重写了一个程序集，那么通常应该保持相同的模式，即Mono.Cecil和工具 a la PostSharp（我假设，未确认）通常也采用相同的参数和/或可以内联进行签名。
Microsoft.Common.targets excerpt
Microsoft.Common.targets 摘录
<Target Name="ResolveKeySource"
Condition="$(SignManifests) == 'true' or $(SignAssembly) == 'true'">
<ResolveKeySource ...
KeyFile="$(AssemblyOriginatorKeyFile)"
CertificateFile="$(ManifestKeyFile)"
SuppressAutoClosePasswordPrompt="$(BuildingInsideVisualStudio)">
<Output TaskParameter="ResolvedKeyFile" PropertyName="KeyOriginatorFile" ..."/>
<Output TaskParameter="ResolvedKeyContainer" PropertyName="KeyContainerName" ... "/>
Microsoft.CSharp.targets excerpt
Microsoft.CSharp.targets 摘录
<Csc ...
KeyContainer="$(KeyContainerName)"
KeyFile="$(KeyOriginatorFile)" />
For completeness, here's how to programmatically infer the SDK path relevant to the target you are compiling (tested on 4.0 but same approach is possible all the way back to 2.0, i.e. Microsoft.Common.targetshas processed this data for some time):
为了完整起见，以下是如何以编程方式推断与您正在编译的目标相关的 SDK 路径（在 4.0 上测试，但同样的方法可以一直回到 2.0，Microsoft.Common.targets即已处理此数据一段时间）：
<Target Name="ResolveSNToolPath" Condition=" 'true' == '$(SignAssembly)' ">
<PropertyGroup>
<_SdkToolsBinDir Condition=" '' == '$(_SdkToolsBinDir)' ">$(TargetFrameworkSDKToolsDirectory)</_SdkToolsBinDir>
<SNToolPath Condition=" '' == '$(SNToolPath)' ">$(_SdkToolsBinDir)SN.exe</SNToolPath>
</PropertyGroup>
<Error Condition=" 'true' == '$(SignAssembly)' AND !EXISTS( '$(SNToolPath)' )"
Text="In order to resign the assembly, this package requires access to the SN.EXE tool from the Windows Platform SDK, which was not found.
The location derived was "$(SNToolPath)".
Please either:
1) supply a correct path to your SDK Tools bin directory containing SN.EXE by setting %24(_SdkToolsBinDir) or %24(TargetFrameworkSDKToolsDirectory)
OR
2) supply a correct complete path to your SN.EXE signing tool by setting %24(SNToolPath)" />
</Target>
For total completeness, here's how you would leverage the outputs of this process to run SN.exe
为了完整起见，以下是您将如何利用此过程的输出来运行 SN.exe
<Target Name="ResignMyAssembly" Condition="$(SignAssembly) == 'true'">
<Exec Condition=" '$(KeyContainerName)' != '' "
Command=""$(SNToolPath)" -Rca "@(MyAssembly)" "$(KeyContainerName)" " />
<Exec Condition=" '$(KeyContainerName)' == '' "
Command=""$(SlpsSdkProtectSnTool)" -Ra "@(MyAssembly)" "$(KeyOriginatorFile)" " />
回答by lesyk
For VS2017 path was changed to:
C:\Program Files (x86)\Microsoft SDKs\Windows\vX\bin\NETFX X.X.X Tools\.
对于 VS2017 路径更改为：
C:\Program Files (x86)\Microsoft SDKs\Windows\vX\bin\NETFX X.X.X Tools\.
回答by Wasim Khan
For VS2019 the path is C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools\x64\sn.exe
对于 VS2019，路径为 C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools\x64\sn.exe
still now i m unable to use VS command prompt. it showing me message like
现在我仍然无法使用 VS 命令提示符。它向我展示了这样的消息
** Visual Studio 2017 Developer Command Prompt v15.8.9 ** Copyright (c) 2017 Microsoft Corporation
** Visual Studio 2017 开发人员命令提示符 v15.8.9 ** 版权所有 (c) 2017 Microsoft Corporation
[vcvarsall.bat] Environment initialized for: 'x64'
[vcvarsall.bat] 环境初始化为：'x64'
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community>where sn.exe INFO: Could not find files for the given pattern(s).
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community>where sn.exe INFO: 找不到给定模式的文件。
回答by Hamit YILDIRIM
Simply:
简单地：
In windows (according .net framework version \B8.1A..changes in the path), go to =>
在 windows 中（根据 .net framework 版本\B8.1A..路径的变化），转到 =>
C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools
C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 工具
Write your sn.execommand:
编写您的sn.exe命令：
sn -i D:\XX\MYProject.UI.api\MYProject.Gateway\my_certificate.pfx VS_KEY_AD6FD8AFB39B6C43
if it is password protected than it will want the pwd write it down
如果它受密码保护，那么它会希望密码写下来
