MVC: need to build my application with multiple projects
I have an application with many projects. Sometimes I have to remove DLLs and recompile each project before I get a generic clean compiler. I also find when I do an assembly I have to remember to check the DLLs of each project that are stored in the bin folder, compile each project, check the DLL and then run the assembly to get a clean compilation. This is cumbersome. I just want to rebuild once for any changes I make and when I do release. So how do I figure this out?
source to share
We had this problem at the company I work for and are still trying to clear it up.
The first recommendation I would make is not to reference projects for shared libraries in your solutions. You said that you have several dlls in your project bin folder. You have to ask yourself:
- Are these dlls specific to this solution
- Or are they regular libraries that you will use again.
If this is the first one, then I suggest you use this DLL source as a project in your solution. Set up the build order correctly in Visual Studio, and Rebuild Solution ensures everything has a clean build.
However, if it is the latter and you will be reusing these DLLs in other solutions, then they should be in their own solution. Ideally use a build server like Cruise Control or something like that. This will allow you to make changes to the shared library and will automatically recompile with the new version numbers if configured correctly. Then, once your shared library runs your tests and you're happy to publish it, put it in the bin or Dependencies folder in the project you are working on. Link to dll instead of the project as in the previous example. When you build the project, it will use the DLL in bin / Dependencies folder when compiled.
The advantage of this is that if you use a shared library in one solution and release it to a client or project and then change the shared library and release new client solutions / products, you know exactly which version the shared library is in use. Then you can go to your source and get the exact code.
We have used some products and grown them efficiently with every client solution we have implemented. After a dozen projects, we had no idea which version of the code each client was running. Since we switched to Mercurial-related Cruise Control for SSC, we now have a clear understanding of which code versions all of our products and client solutions are using.
source to share
It's hard to know exactly what you need to solve your specific problems without any details, but these tips should help a lot.
when i do the build i have to remember to check the DLL of each project that is stored in the bin folder
First of all, do not store the contents of the bin folder in the original control. Instead, publish the assembly only when you need to share it with someone and put it somewhere else in your source control system. Here's an example of a folder structure that would work just like this.
-MyProduct --main ---- src ---- bin <not tested ---- etc ... -Supplier --My project ---- release number ------ explicitly published dlls
I need to remove the DLL and recompile each project before I get a generic clean compiler.
Sometimes it happens. Use the Rebuild Solution command in Visual Studio.
The problem that can cause this happens more often if you use file references instead of project references. Use links to projects. See this question for details:
If you are unable to use project references for any reason, you can manually change the build order of the solution and set dependencies between projects for a better update.
source to share
I sometimes find that I need to remove the DLL and recompile each project before I have a generic clean compiler.
Right click on solution> Clean Solution. And then rebuild. This will often fix strange build errors.
I also find myself when I do an assembly I have to remember to check the DLLs of each project that are stored in the bin folder, compile each project, check the DLL, and then run the assembly to get a clean compilation.
This is most likely a real problem. Don't add external dll directly to the trash can. Rather, add any third party DLL to a folder at the root of your solution, or indeed anywhere else you can access, but I found the root to be 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 link to each project as needed from your ExtLib: Add Link> Browse: add dlls as needed.
After adding the dlls make sure they are marked as "copy local": References> Build Right Click: Copy Local = True.
If the assemblies you need to specify are associated with the corresponding project, then just add a reference to the project; there is no need to copy the local one 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 in source as needed. Then, whenever anyone pulls the project out of the original control, it will pick up the ExtLib folder and any updated assemblies. Whenever you build, assemblies are referenced by ExtLib and copied to the trash.
As mentioned, never add the bin folder to your source code: YMMV.
source to share