.Net Assembly /dll Sharing and Deploying

Question

hi guys,

We have 3 software products which use the same .net dlls(code + legacy).
All these use common functionality present across 3/4 dlls.

i wanted to know how and where to deploy these dlls.
And which is the most standard way of doing this.

S1] Along with each product in its install dir -- probably easiest way to do. (but if any updates are to happen in the shared dll ..it has to be done for all 3 dlls.)

S2]Put it in common files folder?

S3] Does System GAC help in this?
(Put all 3 in GAC and the code is shared.but im worried about versioning?)

Also how to build a deployable setup for such projects:

D1]pack all dlls in one setup.each setup has its own copy.
but suppose if someone installs software A, then for software B the shared files are already present in the system.

D2]deploy common files in a separate setup and pack with each.try to detect if files are already present if yes dont deploy.(this still doesnt help setup size)
Common folder - should it be GAC or some folder on system? Involves complex setup as it will require check versioning of different shared files.

Also suppose if newer version of the software is to be released and it has to coexist with older version..
how to maintain compatabilty across multiple versions?

Answer 1

Put everything in your application folder. Putting in GAC only if you really have a large number of code to share, and doesn't update all the time.

Answer 2

I would go "S1"+"D1", or "S1"+ClickOnce; it makes for simple deployment and versioning, and is compatible with ClickOnce deployment, xcopy deployment, MSI deployment, web, etc. GAC is not appropriate IMO. Re updates; well, you'll want to test/release them individually, no? I have a cascading build configured on my build server, so if I update a library dll it trickles up and rebuilds everything that uses that dll, and upwards (before anyone says: yes, it detects and eliminates cycles).

The "common folder" approach has issues with dll resolution, so by itself is a real PITA.

The GAC approach would work, but is lots of unnecessary effort, and pretty painful to save a few duplicated dlls. It is also a pain if you need to deploy to a non-admin.

Answer 3

The GAC is the place you want the code to ensure that there is only one copy of each version. Don't worry about versioning with the GAC because it handles storing multiple versions of libraries for you.

But generally unless the library is going to be used a lot I would tend to agree with Ngu's answer and put them in your application folder. This will make deployment a fair bit easier too.

Answer 4

S1 + D1 for sure. About the "if any updates..." : this is a benefit rather than a problem. If you change an assembly you will have to rebuild the using projects. The S1 scenario lets you do that project-by-project, no unneeded dependencies between them.

Do not use the GAC for small libraries, and it is a hassle.

Answer 5

If your releases are well planned then putting dlls in GAC is a good option. Contradictory to this fact, if you are adding any small feature and then releasing your product, then GAC is not at all scalable because then you have to make parallel releases of all your products, which I guess not possible. Also, GAC is used to store dlls having common functionality for all the products which are making use of these dlls. So you have to be sure about the functionality you are providing for all the products. This is not at all advisable to add different functionality for every product and storing dlls in GAC. For this you have to be very precise about your version system and releases.