找不到sn.exe来签署程序集

pro*_*ice 49 c# msbuild sn.exe

我看了看C:\Program Files\Microsoft.NET,我看不到任何SN.exe文件.

我安装了.NET 3.5运行时; 还不够吗?

Cam*_*per 81

您需要安装Windows SDK 6.0a,而不仅仅是运行时.

如果你已经安装了VS2008,你会发现它已经安装了,sn.exe将在这里:

C:\ Program Files\Microsoft SDKs\Windows\v6.0A\Bin\sn.exe

否则,如果您没有安装VS2008,可以在此处单独下载SDK .

SDK中没有文件sn.exe.当前版本的SDK是6.1,也许他们在此版本中删除了sn.exe.

  • 在使用VS2010的Windows 7 64位上,sn.exe的路径是`C:\ Program Files(x86)\ Microsoft SDKs\Windows\v7.0A\Bin\sn.exe` (29认同)

Ica*_*rus 17

  • 打开命令提示符
  • 类型 cd \
  • 类型 dir /s sn.exe
  • 你会得到类似的输出

    Volume in drive C has no label.

    Volume Serial Number is XXXX-XXXX.

目录 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
Run Code Online (Sandbox Code Playgroud)

你找到了目录:)
如果没有,sn.exe你的系统就没有了.然后安装SDK.


Rub*_*ink 5

我相信你有你的理由——而且肯定有很多情况是SN.exe不可避免的和/或适当的(延迟签名就是其中之一)。(我已经对 Q 和已接受的 A 进行了+1,并且不会以任何方式质疑它们的优点,所以如果它不适用于您的情况,请忽略这一点)

请注意,在实践中很少需要 -驱动编译器[等]SN.exe的接线都[有效地]考虑 .proj 文件中的标志,并有条件地将密钥传递给编译器等。可以通过一次内联装配完成所有工作(主要是出于性能原因)。Microft.<lang>.targetsAL.exeSignAssembly

此逻辑还处理.snk.pfx密钥之间的区别(受密码保护并被秘密到密钥容器中)。根据哪种形式,运行时目录中会有一个KeyContainerNameKeyOriginatorFile属性解析Microsoft.Common.targets- 搜索ResolveKeySource.

如果您需要执行 a 的原因SN是因为您刚刚重写了程序集,则通常应该保持相同的模式,即Mono.CecilPostSharp 的工具(我假设,未确认)通常也采用相同的参数和/或可以进行进行内联签名。


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" ... "/>
Run Code Online (Sandbox Code Playgroud)

Microsoft.CSharp.targets 摘录

    <Csc  ...
          KeyContainer="$(KeyContainerName)"
          KeyFile="$(KeyOriginatorFile)" />
Run Code Online (Sandbox Code Playgroud)

为了完整起见,以下是如何以编程方式推断与您正在编译的目标相关的 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 &quot;$(SNToolPath)&quot;.

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>
Run Code Online (Sandbox Code Playgroud)

为了完整起见,以下是您如何利用此过程的输出来运行 SN.exe

<Target Name="ResignMyAssembly" Condition="$(SignAssembly) == 'true'">
  <Exec Condition=" '$(KeyContainerName)' != '' " 
    Command="&quot;$(SNToolPath)&quot; -Rca &quot;@(MyAssembly)&quot; &quot;$(KeyContainerName)&quot; " />
  <Exec Condition=" '$(KeyContainerName)' == '' " 
    Command="&quot;$(SlpsSdkProtectSnTool)&quot; -Ra &quot;@(MyAssembly)&quot; &quot;$(KeyOriginatorFile)&quot; " />
Run Code Online (Sandbox Code Playgroud)


les*_*syk 5

对于 VS2017 路径更改为: C:\Program Files (x86)\Microsoft SDKs\Windows\vX\bin\NETFX X.X.X Tools\.