 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / Interop / January 2005Any reason NOT to strong-name an assembly?
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. > Can anyone think of a reason why a 3rd party vendor writing .NET > components [quoted text clipped - 12 lines] > > TJ Hi, > If you were a third-party vendor, > would you strong-name your assemblies?? Yes, definitely. No good reason not to do so.  SignaturePatrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr > 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. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too > 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. SignatureThere are 10 kinds of people: those who understand binary and those who don't. > > It forces anything that references your assembly to also be strongly > > named, doesn't it? > > 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... > > 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. Indeed. I wonder whether that's what MSDN was *trying* to say, but got it the wrong way round.... SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too > Hmm. MSDN says: > [quoted text clipped - 5 lines] > 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. SignaturePatrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr 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 > > Hmm. MSDN says: > > [quoted text clipped - 13 lines] > IMHO, they actually meant that a strong-named assembly can only > reference other strong-named assemblies. For security reasons. > > Hmm. MSDN says: > > [quoted text clipped - 8 lines] > 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. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too 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. SignaturePhil 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 [quoted text clipped - 12 lines] > > TJ > 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. >> Can anyone think of a reason why a 3rd party vendor writing .NET >> components [quoted text clipped - 14 lines] >> >> TJ
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.