Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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?
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.