When to use Strong Names (sn.exe)

  • Thread starter Thread starter Ross
  • Start date Start date
R

Ross

Hi,
I am new to COM's and I was wondering when do I use the sn.exe utility.
I created an assembly in .NET (I did not create a strong name) and ran
it using VB.NET and had no problems.

Do I only use strong name when I have an older COM that integrates with
..NET?

Thank you in advance

Ross
 
Strong names are a security feature designed for software distributors
to guarantee to their customers that nobody has messed with their
assembly.

For example... Microsoft ships mscorlib.dll strong named. People
around the world use this assembly in every managed application. You
can imagine how a malicious hacker would like to modify this assembly
on other people's computers so that it would do new and "interesting"
things for them.

This is not possible though because Microsoft has "strong named" the
assembly. Any assembly that references it knows the public key and
expects it to match. If you change the assembly you need Microsoft's
private key to re-sign it. Without re-signing it, you can't use it.

The short answer to your question is, "Don't use strong names unless
you are shipping assemblies to other people." A slightly longer answer
would be, "Only use strong names when the recipient of an assembly
needs reassurance that the assembly will not change unless you change
it for them."

I hope this helps you.
 
Nick said:
Strong names are a security feature designed for software distributors
to guarantee to their customers that nobody has messed with their
assembly.

For example... Microsoft ships mscorlib.dll strong named. People
around the world use this assembly in every managed application. You
can imagine how a malicious hacker would like to modify this assembly
on other people's computers so that it would do new and "interesting"
things for them.

This is not possible though because Microsoft has "strong named" the
assembly. Any assembly that references it knows the public key and
expects it to match. If you change the assembly you need Microsoft's
private key to re-sign it. Without re-signing it, you can't use it.

The short answer to your question is, "Don't use strong names unless
you are shipping assemblies to other people." A slightly longer answer
would be, "Only use strong names when the recipient of an assembly
needs reassurance that the assembly will not change unless you change
it for them."

I hope this helps you.

Strong names guarantee name uniqueness by relying on unique key pairs.
No one can generate the same assembly name that you can, because an
assembly generated with one private key has a different name than an
assembly generated with another private key.

Strong names protect the version lineage of an assembly. A strong name
can ensure that no one can produce a subsequent version of your
assembly. Users can be sure that a version of the assembly they are
loading comes from the same publisher that created the version the
application was built with.

Strong names provide a strong integrity check. Passing the .NET
Framework security checks guarantees that the contents of the assembly
have not been changed since it was built. Note, however, that strong
names in and of themselves do not imply a level of trust like that
provided, for example, by a digital signature and supporting certificate.

Reasons i can think of for strong naming (other than
distribution/versioning)
1. You want your assembly to reside in the GAC (global assembly cache)
2. Registering for Interop
3. Calling other strong named assemblies

-Rob Schieber
 
Short and simple list:

1. You want to make a global assembly (in the GAC)
2. You are using Interop or COM+
3. You need to send out versions of your assembly to clients who desire to
test if it has been tampered with
4. You need different versions of your assembly for different languages
(cultures)
5. You have some apps that require an older version of your DLL (GAC can
hold many versions of the same DLL)


--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************
 
Back
Top