Cannot find sn.exe to sign Assembly

Asked 8/10, 2009 at 6:6 Answered 4/7, 2019 at 11:53

Solved c#msbuild sn.exe

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 ?

Unhesitating answered 8/10, 2009 at 6:6 Comment(1)

If you use Visual Studio command prompt it should work out of the box – Notability 26/1, 2015 at 16:23

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.

Electrotechnology answered 8/10, 2009 at 6:15 Comment(3)

What about the 64 bit version? – Gemeinschaft 13/3, 2012 at 12:55

For me on a Windows 7 64-bit using VS2010, the path to sn.exe was C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\sn.exe – Sustenance 26/4, 2012 at 18:24

link is broken. – Roane 17/4, 2019 at 12:26

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.

Disencumber answered 28/9, 2012 at 10:39 Comment(0)

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

Impudence answered 2/10, 2018 at 11:17 Comment(0)

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

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="&quot;$(SNToolPath)&quot; -Rca &quot;@(MyAssembly)&quot; &quot;$(KeyContainerName)&quot; " />
  <Exec Condition=" '$(KeyContainerName)' == '' " 
    Command="&quot;$(SlpsSdkProtectSnTool)&quot; -Ra &quot;@(MyAssembly)&quot; &quot;$(KeyOriginatorFile)&quot; " />

Cumulonimbus answered 9/5, 2013 at 14:59 Comment(0)

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

Ashton answered 8/10, 2009 at 6:10 Comment(0)

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

Snuffy answered 4/7, 2019 at 11:53 Comment(0)

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\

Drysalter answered 8/10, 2009 at 6:11 Comment(2)

No, that is the runtime folder. That contains some tools, but not sn. – Frohne 8/10, 2009 at 14:15

@HenkHolterman (and OP) have edited the answer to make it clearer. I submit that a) there was an important point that the other answers didnt cover b) we should all remove our comments as they dont make sense with the answer as it is c) the downvoter should remove the downvote assuming there is agreement. As for how I'll remember to delete this... :) – Cumulonimbus 9/5, 2013 at 15:4

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

[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).

Latchstring answered 4/7, 2019 at 5:59 Comment(0)

Microsoft.Common.targets excerpt

Microsoft.CSharp.targets excerpt

Recommended topics

Hot tags