MVC: Need to build my application with multiple projects

Question

I have an application with many projects. I sometimes find I have to delete the dlls and recompile each project before I get an overall clean compile. I also find when i do a build I have to remember to checkout the dlls of each project which are stored in the bin folder, compile each project, check in the dll and then run the build to get a clean compile. This is cumbersome. I just want to rebuild once for any changes I make, and when I make a release. So how do I sort this out?

Answer 1

It's hard to know exactly what you need to fix your specific problems without more details, but these tips should help a lot.

when i do a build I have to remember to checkout the dlls of each project which are stored in the bin folder

First of all, do not store your bin folder contents in source control. Instead, publish a build only when you need to share it with someone, and put it in a different place in your source control system. Here's an example of a folder structure that would work that way.

-MyProduct --main ----src ----bin << not checked in ----etc... -Distribution --MyProject ----release number ------explicitly published dlls

I have to delete the dlls and recompile each project before I get an overall clean compile.

Sometimes this happens. Use the Rebuild Solution command in Visual Studio.

A problem that can cause this to happen more frequently is if you use file references instead of project references. Use project references. See this question for details on that:

Project Reference Vs File Reference?

If you can't use project references for some reason, you can manually change the build order of the solution, and setup dependencies between projects for better updating.

Answer 2

We had this problem in the company I work for and we're still trying to clean it all up.

The first recommendation I'd make is don't have Project References to common libraries in your solutions. You said you have some inhouse dlls in the bin folder of your project. You need to ask yourself:

• Are these dlls specific to this solution
• Or, are they common libraries you will use again

If it's the former, then I suggest you have that dlls source as a project in your solution. Set the Build Order correctly in Visual Studio and Rebuild Solution will ensure everything gets a clean build.

However, if it's the latter and you will reuse those dlls in other solutions, then they should be in their own solution. Ideally use a Build Server such as Cruise Control or something like it. This will allow you to make changes to the common library and it will recompile it with new version numbers automatically, provided you set it up correctly. Then once your common library has passed its tests and you are happy to release it, put into a "bin" or "Dependencies" folder in the project you are working on. Reference that dll instead of the Project as in the previous example. When you build your project it will use the dll in the bin/Dependencies folder when compiling.

The advantage of this is that if you use a common library in one solution and release it to a client or as a project, then change the common library and release new client solutions/products, you will know exactly which version of the common library is in use. Then you can go to your source control and pull the exact code.

We were using some products and effectively growing them with each client solution we implemented. After a dozen or so projects we had no idea what version of code each client was running. Since we moved to Cruise Control linked with Mercurial for SSC we now clearly know what versions of code all of our products and client solutions are using.

Answer 3

I sometimes find I have to delete the dlls and recompile each project before I get an overall clean compile.

Right-click the solution > Clean Solution. And then re-build. This will often times clear up strange build errors.

I also find when i do a build I have to remember to checkout the dlls of each project which are stored in the bin folder, compile each project, check in the dll and then run the build to get a clean compile.

This is most likely the real issue. Do not add the external dll's directly to the bin. Rather, add any 3rd party dll's to a folder at the root of your solution, or really, anywhere else that you can access, but I find the root a good place:

 - Solution Folder
   - ExtLib (place all your 3rd party assemblies here; use sub-folders if needed)
   - Project A
   - Project B
   - MySolution.sln

Then add a reference to each project as needed from your ExtLib: Add Reference > Browse: add dll's as needed.

Once the dll's are added, make sure they are marked as "copy local": References > Right-Click assembly: Copy Local = True.

If the assemblies you need to reference are in a related project, then just add a project reference; no need to copy local as VS will take care of that for you.

With the above you can keep your 3rd party assemblies in your ExtLib folder and add to source control if needed. Then, whenever anyone pulls down the project from source control, they'll pick up ExtLib folder and any updated assemblies. Whenever you build, the assemblies are referenced from the ExtLib and copied to the bin.

As others have mentioned, do not ever, ever, ever add your bin folder to source control: YMMV.