With continuous integration in .NET, is it acceptable to reference DLLs of rarely-changing assemblies

continuous integrationnet

My company is looking to implement a CI solution pretty soon, and I am worried about one thing in particular… we are scaling up, which means our solutions are growing with more projects. One thing I wanted to look into is to split off rarely changed projects into a separate project, and then having other projects simply reference the compiled DLL, rather than including the projects in their solutions.

For example…

  • /BLL/DataFramework
  • /BLL/OrmFramework
  • /BLL/OrmDataAdapter
  • /BLL/…
  • /WebUI/MyWebSite

The Data and ORM projects would rarely be changed, but if not referenced as DLLs would add bloat to all solutions.

Instead I'd like to exclude them from the project and have them build to a Libraries folder (or something similar), so that:

  • /BLL/…
  • /Libraries
  • /WebUI/MyWebsite

Where the ORM and Data assemblies .DLLs are in the Libraries folder.

So the question is…

Is there any reason this would not work with Continuous Integration?

Could I have one solution with these rarely updated classes that will build to the library folder during CI, first, and followed by the other solutions?

Edit: To be clear… we want to keep these projects in the CI cycle, but to not directly reference their projects in every solution.

Best Answer

This would work. I do something similar in that we treat those rarely changed projects as Core Framework/Architecture dlls and they exist in their own solution. The dlls are published to a reference location and the other solutions reference these dlls in this location as required.

Although rare sometimes a bug is found or an new requirement is identified then a change is scheduled for these Framework/Architecture projects and they are built, unit tested and integration tested against those projects that use them.

Once testing has been completed they are released to the reference location and other projects pick them up on their next build.

All of the non Framework/Architecture projects are on a CI cycle and we have never had an issue with this approach.

Another advantage of this approach is that you have a single code base for these Framework/Architecture projects making it easy to control access if you have some IP and also to ensure that all versions of the application that need them are running on the same version.

Related Topic