Share via

Strong name EXEs

  • Article

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

  • Anonymous
    April 09, 2005
    I thought it was always a good idea to strongly name all your assemblies to make it "tamperproof", or perhaps I've missed something?
  • Anonymous
    April 09, 2005
    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?
  • Anonymous
    April 09, 2005
    The comment has been removed
  • Anonymous
    April 09, 2005
    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?
  • Anonymous
    April 09, 2005
    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.
  • Anonymous
    April 09, 2005
    Doesn't it make it easier to set up an enterprise policy that says "we trust anything we signed"?
  • Anonymous
    April 10, 2005
    I strongly name and digitally sign all my assemblies.
  • Anonymous
    April 10, 2005
    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.
  • Anonymous
    April 10, 2005
    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...!
  • Anonymous
    April 10, 2005
    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.
  • Anonymous
    April 10, 2005
    The comment has been removed
  • Anonymous
    April 10, 2005
    The comment has been removed
  • Anonymous
    April 11, 2005
    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
  • Anonymous
    April 11, 2005
    Henry,

    You can add a CAS policy based on the network share to achieve the same thing, right?
  • Anonymous
    April 11, 2005
    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.
  • Anonymous
    April 11, 2005
    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.
  • Anonymous
    April 12, 2005
    The comment has been removed
  • Anonymous
    April 12, 2005
    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 hackersRus.com 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. (http://blogs.msdn.com/shawnfa/archive/2005/04/11/407417.aspx)

    -Shawn
  • Anonymous
    April 13, 2005
    The comment has been removed