web-dev-qa-db-fra.com

Impossible de trouver sn.exe pour signer l'assembly

J'ai examiné C:\Program Files\Microsoft.NET et je ne vois aucun SN.exe fichier.

J'ai le runtime .NET 3.5 installé; n'est-ce pas suffisant?

c#msbuildsn.exe
48
programmernovice

Vous devez installer le SDK Windows 6.0a, pas seulement le runtime.

Si vous avez installé VS2008, vous constaterez qu'il est déjà installé et sn.exe sera ici:

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

Sinon, si VS2008 n'est pas installé, vous pouvez télécharger le SDK individuellement ici .

Le fichier sn.exe n'est pas disponible dans le SDK. La version actuelle du SDK est 6.1, ils ont peut-être supprimé sn.exe dans cette version.

79
Cam Soper
  • invite de commande ouverte
  • tapez cd \
  • tapez dir /s sn.exe

  • vous obtiendrez quelque chose comme

    Volume in drive C has no label.

    Volume Serial Number is XXXX-XXXX.

Répertoire de 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

Vous avez trouvé le répertoire :)
sinon, il n'y a pas de sn.exe dans votre système. Installez ensuite le SDK.

17
Icarus

Pour VS2017, le chemin d'accès a été remplacé par: C:\Program Files (x86)\Microsoft SDKs\Windows\vX\bin\NETFX X.X.X Tools\.

3
lesyk

Cela fait partie du SDK (.NET, ou maintenant Windows SDK )

3
psychotik

Je suis sûr que vous avez vos raisons - et il y a certainement de nombreux cas où SN.exe est inévitable et/ou approprié (signature différée pour l'un). (Et j'ai attribué +1 au Q et au A accepté et je ne conteste aucunement leur mérite, veuillez donc ne pas en tenir compte si cela ne s'applique pas dans votre cas)

Notez que SN.exe est rarement nécessaire en pratique - le câblage dans Microft.<lang>.targets qui pilotent les compilateurs [et AL.exe etc.] tous [effectivement] prennent en compte l'indicateur SignAssembly dans le fichier .proj et transmettent conditionnellement la clé au (x) compilateur (s), etc. afin qu'il puisse faire tout le travail en une seule touche de l'Assemblée en ligne (principalement pour des raisons de performance).

Cette logique traite également de la distinction entre .snk et .pfx clés (qui sont protégées par mot de passe et sont secrètes dans un conteneur de clés). Selon le formulaire, il existe alors une propriété KeyContainerName ou KeyOriginatorFile résolue par Microsoft.Common.targets dans le répertoire Runtime - Recherchez ResolveKeySource.

Si la raison pour laquelle vous devez faire un SN est parce que vous venez de réécrire un assembly, le même modèle devrait généralement tenir, c'est-à-dire Mono.Cecil et les outils à la PostSharp (je suppose, non confirmés) prennent généralement les mêmes arguments et/ou peuvent être faits pour faire la signature en ligne.

Extrait 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" ... "/>

Extrait Microsoft.CSharp.targets

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

Pour être complet, voici comment déduire par programme le chemin du SDK correspondant à la cible que vous compilez (testé sur 4.0 mais la même approche est possible jusqu'à 2.0, c'est-à-dire Microsoft.Common.targets traite ces données depuis un certain temps):

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

Pour une complétude totale, voici comment tirer parti des sorties de ce processus pour exécuter 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; " />
3
Ruben Bartelink

Non, on dirait que vous avez besoin du SDK pour cela :(

Pour info, le Runtime lui-même ne serait pas sous C:\Program Files\Microsoft.NET - tous ses fichiers sont en direct [uniquement] sous C:\Windows\Microsoft.NET\vXXXXXX\

1
leppie

Pour VS2019, le chemin est C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools\x64\sn.exe

encore maintenant je ne peux pas utiliser l'invite de commande VS. il me montre un message comme

** Invite de commandes du développeur Visual Studio 2017 v15.8.9 ** Copyright (c) 2017 Microsoft Corporation

[vcvarsall.bat] Environnement initialisé pour: 'x64'

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community> où sn.exe INFO: Impossible de trouver les fichiers pour le (s) modèle (s) donné (s).

0
Wasim Khan

simplement:

Dans Windows (selon la version du framework .net \ B8.1A .. changements dans le chemin), allez à =>

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

Écrivez votre commande sn.exe:

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

s'il est protégé par mot de passe, il voudra que le pwd l'écrive

0
Hamit YILDIRIM