Strong Naming Cons???

  • Thread starter Thread starter Ted
  • Start date Start date
T

Ted

What are the negatives to strongly naming assemblies? Why wouldn't we
want to strongly name all assemblies that we ship as part of our
products?

Thanks
Ted
 
Because its not the "in" thing to do.

Hey we all follow design patterns dont we :D gotta keep up with the joneses,
and not think for ourselves.
 
For one thing, any code you have that uses this assembly, will need to be
recompiled with a reference to the new assembly with the newer version.
 
Ted said:
What are the negatives to strongly naming assemblies? Why wouldn't we
want to strongly name all assemblies that we ship as part of our
products?
Click to expand...

At least two that I can think of:
1. Strong named assemblies can only reference other strong named assemblies.
If you need to reference a non-strong named assembly external to your
project then you're out of luck.
2. Hotfixes. If your product includes many assemblies (DLL's) and you want
to ship only one of them as a hotfix, you will not be able to because your
other assemblies will reject it because of version problems. Two
workarounds for this issue are, a. Don't bump up the version. (ick), or b.
Use the Framework configuration tool to forward the old version to the new
version. (Difficult for your customers).

-- Alan
 
Serialization may be affected. If you have classes that need to be
serialized, the engine includes type information in the serialized data,
that way it can be reconstituted later. If you the AssemblyFormat property
is not set correctly, you could end up with a situation here you have stored
some data, upgraded your application (maybe because of a bug fix), and then
error when you try to load your serialized database (even though nothing in
that particular class has changed).

I would say maintenance is a big drawback. Unless your assemblies need to
be placed in the GAC, or run as COM+ component, or some other special case,
strong-naming them probably is not necessary.
 
Back
Top