Any reason NOT to strong-name an assembly?

[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

 

[Marina]

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.

 

[Patrick Philippot]

Hi,

If you were a third-party vendor,
would you strong-name your assemblies??

Yes, definitely. No good reason not to do so.

 

[Jon Skeet [C# MVP]]

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.

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.

 

[Frank Oquendo]

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.

Try strong-naming an assembly with unsigned references.

 

[Jon Skeet [C# MVP]]

No.

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.

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

 

[Patrick Philippot]

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...

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.

 

[Guest]

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

 

[Phil Wilson]

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.

 

[Jon Skeet [C# MVP]]

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

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.

Indeed.

 

[David Levine]

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.

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

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