当前位置： 文江博客话题详情

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

发布于 2024-08-07 06:11:31 字数 119 浏览 3 评论 0原文

我查看了 C:\Program Files\Microsoft.NET，但看不到任何 SN.exe 文件。

我安装了 .NET 3.5 运行时；这还不够吗？

原文

I looked into C:\Program Files\Microsoft.NET and I can't see any SN.exe file.

I have .NET 3.5 runtime installed; isn't that enough ?

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论， 你可以免费 注册 一个本站的账号。

评论（8）

濫情▎り 2024-08-14 06:11:31

您需要安装 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。

You need to install the Windows SDK 6.0a, not just the runtime.

If you've installed VS2008, you'll find it's already installed, and sn.exe will be here:

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.

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.

回复 原文
执手闯天涯 2024-08-14 06:11:31
  • 打开命令提示符
  • 类型cd \
  • 类型dir /s sn.exe

  • 你将得到类似的输出

    驱动器 C 中的卷没有标签。

    卷序列号为 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

您已找到该目录:)
如果没有，则您的系统中没有 sn.exe。然后安装SDK。

  • 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.

Directory of 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.exe in your system. Install SDK then.

回复 原文
Bonjour°[大白 2024-08-14 06:11:31

对于VS2017，路径更改为：
C:\Program Files (x86)\Microsoft SDKs\Windows\vX\bin\NETFX XXX Tools\。

For VS2017 path was changed to:
C:\Program Files (x86)\Microsoft SDKs\Windows\vX\bin\NETFX X.X.X Tools\.

回复 原文
不可一世的女人 2024-08-14 06:11:31

我确信您有自己的理由 - 并且在很多情况下 SN.exe 是不可避免的和/或适当的（延迟签名就是其中之一）。 （我已经对 Q 和已接受的 A 进行了+1，并且不会以任何方式质疑它们的优点，因此如果它不适用于您的情况，请忽略这一点）

在实践中很少需要 SN.exe - 驱动编译器的 Microft..targets 中的接线[和 AL.exe > 等]所有[有效地]考虑.proj文件中的SignAssembly标志，并有条件地将密钥传递给编译器等。这样它就可以在一个单一的文件中完成所有工作内联装配的触摸（主要是出于性能原因）。

此逻辑还处理 .snk 和 .pfx 密钥（受密码保护并被秘密到密钥容器中）之间的区别。根据哪种形式，运行时目录中会有由 Microsoft.Common.targets 解析的 KeyContainerName 或 KeyOriginatorFile 属性 - 搜索 <代码>ResolveKeySource。

如果您需要执行 SN 的原因是因为您刚刚重写了程序集，则通常应该保持相同的模式，即 Mono.Cecil 和 PostSharp 等工具（我假设（未证实）通常也采用相同的参数和/或可以进行内联签名。

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 摘录

    <Csc  ...
          KeyContainer="$(KeyContainerName)"
          KeyFile="$(KeyOriginatorFile)" />

为了完整起见，以下是如何以编程方式推断与您正在编译的目标相关的 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>

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

<Target Name="ResignMyAssembly" Condition="$(SignAssembly) == 'true'">
  <Exec Condition=" '$(KeyContainerName)' != '' " 
    Command=""$(SNToolPath)" -Rca "@(MyAssembly)" "$(KeyContainerName)" " />
  <Exec Condition=" '$(KeyContainerName)' == '' " 
    Command=""$(SlpsSdkProtectSnTool)" -Ra "@(MyAssembly)" "$(KeyOriginatorFile)" " />

I'm sure you have your reasons -- and there are definitely plenty cases where SN.exe is 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)

Note that SN.exe is rarely needed in practice - the wiring in Microft.<lang>.targets that drive the compilers [and AL.exe etc.] all [effectively] take the SignAssembly flag 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).

This logic also deals with the distinction between .snk and .pfx keys (which are password protected and get secreted into a Key Container). Depending on which form, there is then either a KeyContainerName or KeyOriginatorFile property resolved by Microsoft.Common.targets in the Runtime directory - Search for ResolveKeySource.

If the reason you need to do a SN is because you've just rewritten an assembly, the same pattern should generally hold, i.e. Mono.Cecil and tools a la PostSharp (I assume, not confirmed) generally also take the same arguments and/or can be made to do the signing inline.

Microsoft.Common.targets excerpt

<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

    <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.targets has processed this data for some time):

<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

<Target Name="ResignMyAssembly" Condition="$(SignAssembly) == 'true'">
  <Exec Condition=" '$(KeyContainerName)' != '' " 
    Command=""$(SNToolPath)" -Rca "@(MyAssembly)" "$(KeyContainerName)" " />
  <Exec Condition=" '$(KeyContainerName)' == '' " 
    Command=""$(SlpsSdkProtectSnTool)" -Ra "@(MyAssembly)" "$(KeyOriginatorFile)" " />

回复 原文
够运 2024-08-14 06:11:31

它是 SDK（.NET，或者现在的 Windows SDK 的一部分）

It's part of the SDK (.NET, or now the Windows SDK)

回复 原文
一江春梦 2024-08-14 06:11:31

简单：

在windows中（根据.net框架版本\B8.1A..路径的变化），转到=>;

C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1
工具

编写您的 sn.exe 命令：

sn -i D:\XX\MYProject.UI.api\MYProject.Gateway\my_certificate.pfx VS_KEY_AD6FD8AFB39B6C43

如果它受密码保护，则需要密码将其写下来

Simply:

In windows (according .net framework version \B8.1A.. changes in the path), go to =>

C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1
Tools

Write your sn.exe command:

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

回复 原文
﹏雨一样淡蓝的深情 2024-08-14 06:11:31

不，看起来您需要 SDK :(

仅供参考，运行时本身不会位于 C:\Program Files\Microsoft.NET 下 - 所有文件都[仅]位于 下C:\Windows\Microsoft.NET\vXXXXXX\

Nope, looks like you need the SDK for that :(

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\

回复 原文
柏拉图鍀咏恒 2024-08-14 06:11:31

对于 VS2019，路径为 C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools\x64\sn.exe

现在仍然无法使用 VS 命令提示符。它向我显示类似

** Visual Studio 2017 开发人员命令提示符 v15.8.9 的 消息
** 版权所有 (c) 2017 Microsoft Corporation

[vcvarsall.bat] 环境初始化为：'x64'

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community>where sn.exe
信息：找不到给定模式的文件。

For VS2019 the path is 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

** Visual Studio 2017 Developer Command Prompt v15.8.9
** Copyright (c) 2017 Microsoft Corporation

[vcvarsall.bat] Environment initialized for: 'x64'

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community>where sn.exe
INFO: Could not find files for the given pattern(s).

回复 原文
~没有更多了~

关于作者

别靠近我心

暂无简介

0 文章
0 评论
22 人气
发私信

相关话题

更多

热门标签

操作系统 程序设计 IT运维 Linux系统管理 JavaScript 服务器应用 solaris C/C++ PHP Shell BSD Vue.js aix Oracle Python HTML 系统管理 HTML5 CSS 前端
更多

推荐作者

1CH1MKgiKxn9p

文章 0 评论 0

ゞ记忆︶ㄣ

文章 0 评论 0

JackDx

文章 0 评论 0

信远

文章 0 评论 0

yaoduoduo1995

文章 0 评论 0

霞映澄塘

文章 0 评论 0

更多

友情链接

文江博客
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
    原文