Impossible de trouver sn.exe pour signer l'Assemblée

Question

J'ai regardé dans C:\Program Files\Microsoft.NET et je ne peux pas voir SN.exe fichier.

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

Answer 1

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 que sn.exe se trouve ici :

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

Sinon, si vous n'avez pas installé VS2008, 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, peut-être ont-ils supprimé sn.exe dans cette version.

Answer 2

• ouvrir l'invite de commande
• type cd \
• type dir /s sn.exe

• vous obtiendrez un résultat comme

  Volume in drive C has no label.

  Volume Serial Number is XXXX-XXXX.

Répertoire des 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 :)
si non, il n'y a pas de sn.exe dans votre système. Installez ensuite le SDK.

Answer 3

Je suis sûr que vous avez vos raisons et il y a certainement beaucoup de cas où SN.exe est inévitable et/ou appropriée (retarder la signature, par exemple). (Et j'ai fait +1 au Q et au A accepté et je ne conteste en aucun cas leur mérite, alors ne tenez pas compte de ceci si cela ne s'applique pas à votre cas).

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

Cette logique traite également de la distinction entre .snk et .pfx les clés (qui sont protégées par un mot de passe et sont cachées dans un conteneur de clés). En fonction du formulaire, il y a ensuite soit une KeyContainerName ou KeyOriginatorFile propriété résolue par Microsoft.Common.targets dans le répertoire Runtime - Recherchez ResolveKeySource .

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

---

Extrait de 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 de Microsoft.CSharp.targets

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

---

Pour être complet, voici comment déduire par programmation le chemin du SDK correspondant à la cible que vous compilez (testé sur la version 4.0 mais la même approche est possible depuis la version 2.0). 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 être tout à fait complet, voici comment vous pourriez exploiter les résultats 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; " />

Answer 4

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

Answer 5

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 vivent [seulement] sous C:\Windows\Microsoft.NET\vXXXXXX\