Tech Off Thread

7 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

What are PublicKeyTokens?

Back to Forum: Tech Off
  • User profile image
    Minh

    My app uses the Microsoft Enterprise Library, and looking at the reference info (using Reflector), I found this really interesting:

    Microsoft.Practices.EnterpriseLibrary.Caching, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b5eda211d48df7f6

    Microsoft.Practices.EnterpriseLibrary.Common, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b5eda211d48df7f6

    The PublicKeyToken is identical for 2 different DLLs. I thought that PublicKeyTokens are used to uniquely identify DLLs. How can there be 2 identical PublicKeyTokens for 2 DLLs?

  • User profile image
    JPeless

    I am pretty sure if you sign the assembly with the same certificate to create a strongly named assembly it will result in the same publickeytoken.

    Check out the assemblies in your GAC Windows\Assembly directory, usually assemblies from a common vendor share the publickeytoken but I imagine Microsoft is too large to try to get all assemblies signed with the same certificates (although possible).

  • User profile image
    Minh

    Ah, indeed you're right, JPeless.

  • User profile image
    Sven Groot

    It doesn't need to be a certificate. A strong name key will do. See here for more information.

    It's recommended that you always sign your assemblies with a strong name key.

  • User profile image
    Minh

    Sven Groot wrote:
    It's recommended that you always sign your assemblies with a strong name key.
    So that your users can choose to put your assembly into the GAC or not right? Personally, I'd rather do a local copy so that it'd make XCOPY deployment easy.

    Anybody has a GAC preference?

  • User profile image
    Sven Groot

    I never put stuff in the GAC unless I absolutely have to.

    There's still reasons to sign your assembly though. For instance, the CLR doesn't enforce versioning with assemblies that don't have a strong name (if you have foo.exe linked against bar.dll version 1.0 and bar.dll isn't strong named you can replace it with another bar.dll (another version, or a completely different one altogether) and foo.exe won't complain).

    It's also impossible to sign an assembly if not all of its references have a strong name. So if you publish an assembly without a strong name, you're forcing everyone who references your assembly to be unsigned too.

    If you're doing COM InterOp, regasm.exe will complain if your assembly isn't strong named (although it will probably work, it's not recommended).

    If your assembly will ever run from a remote location (intranet, internet), as you know .Net will use CAS to sandbox your app. Administrators can set specific permissions for assemblies, based on their strong name. If your assembly doesn't have a strong name, it must always use the default sandbox permissions.

    Considering all it takes is running sn.exe and specifying the /keyfile option with csc (and with VS2005, it can do both for you), there really is no good reason not to sign your assemblies.

  • User profile image
    TommyCarlier

    Another reason: signed assemblies cannot be modified after compilation. If a signed assembly is modified after being signed, the signature will no longer be valid, and the CLR will refuse to run the code.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.