DLL Hell issues: Assigning strong names

Question

I have two DLLs, app1.dll and app2.dll, that use the same third dll, util.dll, which might have slightly different behavior when built for a specific app.

I want to achieve that app1.dll and app2.dll are isolated concerning the versions of util.dll that they use. On MSDN, I read that assigning a strong name to util.dll is the solution, i.e. that this strong name contains the name and version of the dll as well as the fingerprint due to signing.

I currently build util.dll...

• for app1 with KeyFileApp1.snk and version 1.0.0.1
• for app2 with KeyFileApp2.snk and version 1.0.0.2

and this seams to work on the target machine when deploying the apps with the respective util.dll build.

However, I have some ambiguities:

1. Would it be enough to build util.dll always with version 1.0.0.0 but different key files for both apps and having both apps using the right dll in the end?
2. Are the strong names only considered when putting a dll in the global assembly cache or also when having it as private assembly?

Answer 1

1. yes you can have both with the same name and version, but different public key. Is it good/maintainable solution - up to you. Will likely confuse more people than you want. I.e. no regular person will be able to tell you "public key" used by DLL, but most people can right click and check details to see version (if you set it properly on your assemblies).

2. strong name is always considered. Note that if you have local and GAC copy GAC one will always be used if version in GAC is acceptable.

Notes:

• strong names are "viral" as you can't have strongly named assembly depend on one without strong name. Be careful as you'd need many for your assemblies to be strongly signed (not a bad thing by itself) and have good versioning plan.
• you may eventually endup with multiple versions of the same assembly loaded into process - either prepare for it or use publisher policy to map all versions to latest.