C:\Program Files\Microsoft.NET
と表示されませんSN.exe
ファイル。
.NET 3.5ランタイムがインストールされています。それだけでは不十分ですか?
ランタイムだけでなく、Windows SDK 6.0aをインストールする必要があります。
VS2008をインストールした場合、既にインストールされていることがわかります。sn.exeは次の場所にあります。
C:\ Program Files\Microsoft SDKs\Windows\v6.0A\Bin\sn.exe
それ以外の場合、VS2008をインストールしていない場合は、SDKを個別にダウンロードできます here 。
ファイルsn.exeは、SDKでは使用できません。 SDKの現在のバージョンは6.1であり、おそらくこのリリースでsn.exeが削除されました。
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
ディレクトリを見つけました:)
そうでない場合、システムにはsn.exe
がありません。次にSDKをインストールします。
VS2017の場合、パスはC:\Program Files (x86)\Microsoft SDKs\Windows\vX\bin\NETFX X.X.X Tools\
に変更されました。
これはSDKの一部です(.NET、または Windows SDK )
あなたには理由があると確信しています-SN.exe
が避けられないおよび/または適切な場合は間違いなくたくさんあります(遅延署名)。 (そして、私はQと受け入れられたAを+1しましたが、彼らのメリットに異議を唱えていませんので、あなたの場合に当てはまらない場合は無視してください)
SN.exe
が実際に必要になることはめったにないことに注意してください-コンパイラを駆動するMicroft.<lang>.targets
の配線[およびAL.exe
など]はすべて[有効に]でSignAssembly
フラグを取ります。 projファイルを考慮し、条件付きでキーをコンパイラなどに渡します。これにより、すべての作業をインラインでアセンブリのワンタッチで実行できます(主にパフォーマンス上の理由により)。
このロジックは、.snk
キーと.pfx
キー(パスワードで保護され、キーコンテナに秘密にされる)キーの違いも処理します。どのフォームに応じて、KeyContainerName
またはKeyOriginatorFile
プロパティがランタイムディレクトリのMicrosoft.Common.targets
によって解決されます-ResolveKeySource
を検索します。
SN
を実行する必要がある理由がアセンブリを書き直したためである場合、同じパターンが一般に保持される必要があります。つまり、Mono.Cecil
およびPostSharpのツール(一般的には未確認)同じ引数を取るか、インラインで署名するようにすることができます。
<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" ... "/>
<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)" " />
いいえ、そのためにSDKが必要なようです:(
参考までに、ランタイム自体はC:\Program Files\Microsoft.NET
の下にはありません。すべてのファイルはC:\Windows\Microsoft.NET\vXXXXXX\
の下に[のみ]存在します
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 ** Copyright(c)2017 Microsoft Corporation
[vcvarsall.bat]初期化された環境: 'x64'
C:\ Program Files(x86)\ Microsoft Visual Studio\2017\Community> where sn.exe情報:指定されたパターンのファイルが見つかりませんでした。
単純に:
Windows(.net frameworkバージョン\ 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
パスワードで保護されている場合、pwdに書き留めておく必要があります