Deploying many DLLs for a single DLL

Question

I have a solution with 50 projects.

There are times when I just modify a single class file in a project and I just get a single new DLL.

But there are times when that single project is referencing other projects and those projects are referencing other projects so when I make a small change in one class in one project, I may have to deploye like 30 DLLs.

Why is that.. ? Why are so many new DLLs being created and why do I have to deploy those new DLLs?

Answer 1

It sounds like you have auto versioning on in addition to "specific version=true" set in your references. You would probably want to manually version any of the dlls that don't change a whole lot, which would typically be your "framework" or "lib" dlls or what not. Some shops choose to not compile those assemblies every time and to just put them in a "lib" directory or something, causing your primary assemblies which DO change often to build against the same version of your lib or framework dlls on every build.

At my company, we put all of our framework assemblies on a public network share and leave them there until someone updates it. At that point, we make a new version, and place the new dll out on the share, alerting everyone that a new dll is there. Our reference share looks like the GAC, so we have \\\\\\\\lib.dll for all of our references. Some people check in the actual binaries into source control and reference them from there. What to do is really up to you and your team.

Answer 2

When you build a project you will find in the bin folder the dll and all the dll from the referenced projects. That's the default behaviour because if you want to use your dll you probably need the referenced projects. You don't have necessarily to deploy all the dlls, you just need the changed ones.

Bye, Marco