Any reason NOT to strong-name an assembly?

  • Thread starter Thread starter Tony Jones
  • Start date Start date
T

Tony Jones

Can anyone think of a reason why a 3rd party vendor writing .NET components
would NOT strong name their assemblies? What harm does adding a strong-name
to assembly present - I would think none whatsoever.

Strong-naming the assembly should benefit the end user just in case he/she
wants to reference the assembly in another strong-named assembly or add it
to the GAC. If you were a third-party vendor, would you strong-name your
assemblies??

Any feedback is appreciated.

Thanks

TJ
 
Well, one issue is that if they use auto versioning, all projects using the
assembly would need to be recompiled every time the vendor's dll was
changed. Of course a solution would be to fix the version - which should
probably happen anyway.

But I agree with you. If I am buying a component from a vendor, I would
expect it to be strong named, otherwise I would question the vendor's
knowledge of what they are doing and their professionalism if they didn't do
this.
 
Tony Jones said:
Can anyone think of a reason why a 3rd party vendor writing .NET components
would NOT strong name their assemblies? What harm does adding a strong-name
to assembly present - I would think none whatsoever.
Click to expand...

It forces anything that references your assembly to also be strongly
named, doesn't it? That adds complications for people who want to use
the assemblies but don't have any need for strong names.
 
Jon said:
It forces anything that references your assembly to also be strongly
named, doesn't it?
No.

That adds complications for people who want to use
the assemblies but don't have any need for strong names.
Click to expand...

Try strong-naming an assembly with unsigned references.
 
Frank Oquendo said:
No.
Click to expand...

Hmm. MSDN says:

<quote>
Note All assemblies that reference types in a strong-named assembly
must also have a strong name.
</quote>

On the other hand, presumably all the standard .NET assemblies are
strong-named, and clearly referencing them isn't a problem...
Try strong-naming an assembly with unsigned references.
Click to expand...

Indeed. I wonder whether that's what MSDN was *trying* to say, but got
it the wrong way round....
 
Jon said:
Hmm. MSDN says:

<quote>
Note All assemblies that reference types in a strong-named assembly
must also have a strong name.
</quote>

On the other hand, presumably all the standard .NET assemblies are
strong-named, and clearly referencing them isn't a problem...
Click to expand...

Hi Jon,

I think it's a documentation bug. I can obviously reference strong-named
assemblies from other assemblies not having a strong name.

IMHO, they actually meant that a strong-named assembly can only
reference other strong-named assemblies. For security reasons.
 
hi, no it is not a documentation bug but rather a
missunderstanding. To keep the tamper protection
on the "entire" system the client also has to have
a strongname. But if it don't we still get the strongname
checks during load of all the strongnamed assemblies.

The statement in msdn is true from a security point of
view but not from the developers point.

regards
Daniel
 
Be careful if you serialize types from that assembly, say to disk files or
over .NET Remoting. The deserialization will require the exact same matching
assembly, so changing the strong name later (or assembly version) can cause
some difficulty. Just something to be aware of.
 
Patrick Philippot said:
I think it's a documentation bug. I can obviously reference strong-named
assemblies from other assemblies not having a strong name.
Click to expand...

Yup. I'm not sure why I went with MSDN rather than applying common
sense :)
IMHO, they actually meant that a strong-named assembly can only
reference other strong-named assemblies. For security reasons.
Click to expand...

Indeed.
 
Phil Wilson said:
Be careful if you serialize types from that assembly, say to disk files or
over .NET Remoting. The deserialization will require the exact same
matching assembly, so changing the strong name later (or assembly version)
can cause some difficulty. Just something to be aware of.
Click to expand...

You can control this by implementing a SerializationBinder - it allows you
to tell the deserializer which version of a type to use.
--
Phil Wilson
[Microsoft MVP-Windows Installer]
Definitive Guide to Windows Installer
http://apress.com/book/bookDisplay.html?bID=280

Tony Jones said:
Can anyone think of a reason why a 3rd party vendor writing .NET
components
would NOT strong name their assemblies? What harm does adding a
strong-name
to assembly present - I would think none whatsoever.

Strong-naming the assembly should benefit the end user just in case
he/she
wants to reference the assembly in another strong-named assembly or add
it
to the GAC. If you were a third-party vendor, would you strong-name your
assemblies??

Any feedback is appreciated.

Thanks

TJ
Click to expand...
Click to expand...
 
Back
Top