Kann sn.exe nicht finden, um Assembly zu signieren

• öffnen Sie die Eingabeaufforderung
• art cd \
• art dir /s sn.exe

• du wirst so etwas wie eine Ausgabe bekommen

  Volume in drive C has no label.

  Volume Serial Number is XXXX-XXXX.

Verzeichnis von 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

Du hast das Verzeichnis gefunden :)
Wenn nicht, gibt es kein sn.exe in Ihrem System. Installieren Sie dann das SDK.

Für VS2017 wurde der Pfad geändert zu: C:\Program Files (x86)\Microsoft SDKs\Windows\vX\bin\NETFX X.X.X Tools\.

Es ist Teil des SDK (.NET oder jetzt Windows SDK )

Ich bin sicher, Sie haben Ihre Gründe - und es gibt definitiv viele Fälle, in denen SN.exe Unvermeidlich und/oder angemessen ist (für einen Fall die Unterschrift verzögern). (Und ich habe das Q und das Akzeptierte A +1 gegeben und bestreite deren Verdienst in keiner Weise. Bitte ignorieren Sie dies, wenn es in Ihrem Fall nicht zutrifft.

Beachten Sie, dass SN.exe In der Praxis selten benötigt wird - die Verkabelung in Microft.<lang>.targets, Die die Compiler [und AL.exe Usw.] antreibt, nimmt alle [effektiv] den SignAssembly Markieren Sie dies in der .proj-Datei, und übergeben Sie den Schlüssel unter bestimmten Bedingungen an den Compiler usw., damit er die gesamte Arbeit mit einem einzigen Tastendruck in der Assembly inline erledigen kann (hauptsächlich aus Gründen der Perfektion).

Diese Logik befasst sich auch mit der Unterscheidung zwischen .snk Und .pfx Schlüsseln (die passwortgeschützt sind und in einem Schlüsselcontainer gespeichert werden). Abhängig von der Form gibt es dann entweder eine KeyContainerName oder KeyOriginatorFile Eigenschaft, die mit Microsoft.Common.targets Im Runtime-Verzeichnis aufgelöst wurde - Suche nach ResolveKeySource.

Wenn Sie ein SN ausführen müssen, weil Sie gerade eine Assembly umgeschrieben haben, sollte im Allgemeinen dasselbe Muster gelten, dh Mono.Cecil Und Tools a la PostSharp (ich nehme an, nicht bestätigt). Üblicherweise nehmen Sie auch die gleichen Argumente an und/oder lassen sich die Inline signieren.

Auszug aus 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" ... "/>

Auszug aus Microsoft.CSharp.targets

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

Der Vollständigkeit halber können Sie hier den SDK-Pfad ableiten, der für das zu kompilierende Ziel relevant ist (getestet mit 4.0, aber derselbe Ansatz ist bis 2.0 möglich, d. H. Microsoft.Common.targets Hat diese Daten seit einiger Zeit verarbeitet):

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

Der Vollständigkeit halber sehen Sie hier, wie Sie die Ausgaben dieses Prozesses nutzen, um SN.exe auszuführen

<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; " />

Nein, es sieht so aus, als bräuchten Sie das SDK dafür :(

Zu Ihrer Information, die Runtime selbst wäre nicht unter C:\Program Files\Microsoft.NET - alle seine Dateien leben [nur] unter C:\Windows\Microsoft.NET\vXXXXXX\

Für VS2019 lautet der Pfad C:\Programme (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools\x64\sn.exe

noch jetzt kann ich nicht VS-Eingabeaufforderung verwenden. Es zeigt mir Nachricht wie

** Visual Studio 2017 Developer-Eingabeaufforderung v15.8.9 ** Copyright (c) 2017 Microsoft Corporation

[vcvarsall.bat] Umgebung initialisiert für: 'x64'

C:\Programme (x86)\Microsoft Visual Studio\2017\Community> where sn.exe INFO: Es wurden keine Dateien für die angegebenen Muster gefunden.

Einfach:

In Windows (gemäß .NET Framework-Version \ B8.1A .. Änderungen im Pfad) gehen Sie zu =>

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

Schreiben Sie Ihren sn.exe Befehl:

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

wenn es passwortgeschützt ist, wird es das pwd notieren wollen