Strong name EXEs

You don't need to strongly name EXEs.

When you strongly name an assembly, you want this assembly to be shared by multiple applications.

But you typically don't share applications between applications. An EXE usually is considered as an application.

So you don't need to strongly name EXEs.

Of course if you intend to use your EXEs as libraries, then you may want to strongly name them.

But Why?

Comments (20)

  1. Thomas says:

    I thought it was always a good idea to strongly name all your assemblies to make it "tamperproof", or perhaps I’ve missed something?

  2. Edge says:

    I am by no means an expert with .NET, so this may come off as naive, but wouldn’t an application such as Photoshop (which allows plugins) essentially use the executable as a library?

  3. Thomas,

    "TamperProof" does not mean much to applications. Say you distribute foo.exe, strong name signed. I replace it with my copy of foo.exe, unsigned. For the user of foo.exe, how does he/she know foo.exe is not the original?


    When I say "libraries", I mean assemblies referenced by other assemblies at compile time, like System.dll. Some assembly has burned a reference to it in its metadata. Dynamically loaded modules are not the same as the libraries I mean, since it is a runtime dependency, not a compile time dependency.

  4. Thomas says:

    What I meant is; Doesn’t it prevent people from injecting stuff into your binary and blindly running that?

    Of course, fully replacing an exe is always possible, but surely this makes it harder to tamper with the binary itself, and/or its process image?

  5. Thomas says:

    Also, by strongly naming my assembling I can tell people its from me, not from someone else. Now, this doesn’t mean squad to most endusers, but I imagine it would in an enterprise.

    I remember messing with obfuscation where if you dont delay sign you end up with a messed up binary, and .NET refuses to run it.

  6. Greg Low says:

    Doesn’t it make it easier to set up an enterprise policy that says "we trust anything we signed"?

  7. Trevor says:

    I strongly name and digitally sign all my assemblies.

  8. Shouldn’t the question be, "why not"?

    What about if you wanted to check that a DLL was only being consumed by one entry assembly with a given public key token?

    I always strong name everything. I also wish the runtime would force the check to ensure a signed assembly has not been tampered with.

  9. Kos says:

    So… What about code access security? I can add some attributes in code of my DLL’s to demand that caller must have strong name…. In this situation I must sign my exe…!

  10. laimis says:

    hmmm, link demand based on strong name you say? How about "caspol -s off" ? 🙂 It will turn off code access security and I can use your asssembly from my own written client. I am not saying you guys are wrong, just I hope you keep in mind that CAS can be turned off.

  11. Thomas,

    If I can convince someone to download foo.exe from my web site, why can’t I just replace foo.exe with my copy and be done with it? Why will I want to do all the hard work to tamper your foo.exe?

    Strong name does not mean trust. If you want trust, you use certificate.

    Strong name may be required if you run things directly from a web site or UNC share, so that you can set a CAS policy based on strong name. But once the EXEs are deployed into your local machine, CAS is meaningless.

    And like laimis said, CAS can be turned off.

  12. Regarding Josh Einstein’s "why not" question,

    On enterprise you don’t control the private key. If you need to sign some binaries, you need to submit a request to a private party, and let the private party sign the binaries for you. When you add a new binary for signing, you need to go through additional process. Those processes are time consuming and error-prone.

    The delay sign problem is another problem. Without real signing, you need to turn on delay sign on the test machine, which is another hurdle.

    I am not advertising no strong name. I am saying strong name when make sense.

  13. Henry Boehlert says:

    You can set code access security based on the strong name’s public key.

    This is useful where the exe is to be run from a location that isn’t fully trusted, e.g. a network share.

    Keywords: CodeGroup, StrongNameMembershipCondition

  14. Henry,

    You can add a CAS policy based on the network share to achieve the same thing, right?

  15. Eric Lippert says:

    Saying "but cas can be turned off" is the same as saying "but the admin can delete all their own files, so why set ACLs on anything?"

    CAS isn’t FOR preventing anyone from calling your code — it’s impossible to prevent someone from calling code. CAS is for allowing users and administrators to decide what code runs, and for code providers to describe their security requirements.

  16. Eric,

    This is different. Like laimis said, I can turn off CAS so that I can use a piece of functionality. I did not turn off CAS to shoot myself in the foot.

  17. I think this post represents a very bad direction to send people in. Tamperproofing and security are two VERY valid benefits of strong naming in addition to versioning (or sharing assemblies as you put it). Even if someone replaces my foo.exe with an identically named executable, anyone can easily check if it is really my foo by looking at the public key. Yes, if the world is really a facade and someone spoofs my public key, all bets are off. If there was as trusted public key source as with code signing certificates that would be nice, but if people always pull their installations from my web site, or register with me after install then then realistically speaking the risk is minimal. And note that wholesale replacement is the ONLY way to tamper with my foo.exe – simple patching won’t work and that’s a HUGE benefit. Security policy can also be set via the public key, and I can restrict access to functionality in my libraries by restricting the public key of callers. I don’t really understand your point about the hassle of having a third party sign your assemblies. The majority of files in a product are shared assemblies, what’s one more .exe to sign?

  18. You may be turning off CAS so that you can run an application off the network share, and not be intending to shoot yourself in the foot, however you’re still be pulling that trigger anyway. Since the security on/off setting is machine wide, as soon as you flip that switch, you’ve disabled security for all managed code. This means that while you’re running your app off of the share, any IE hosted control from can now own your machine.

    I posted some more thoughts on this over on my blog, but for some reason CommunityServer didn’t seem to setup the trackback. (


  19. Interesting.

    My original observation is from Windows team, where binaries are dropped into the box. CAS does not play there.

    Seems most folks believe CAS is important scenario. I buy that.

    Thanks for the discussion.

Skip to main content