Our code base has two ASP.NET MVC applications, several WinForm applications, and an assortment of console apps and WCF services. They are all based on the same set of domain class libraries, data access layer (NHibernate driven), and some infrastructure classes (common extension methods, 3rd party binaries, and abstract business logic).
To ensure reference integrity between applications, we have a solution called Builder. Builder contains every single project and recompiles all DLLs in a local workspace. This has worked well so far, but is becoming unmanageable, taking longer and longer to build.
We’re looking to split up the code into more specific assemblies while retaining reference integrity. If someone changes our domain class, the rest of the team needs to rebuild Domain.dll, for example. It is bad practice to add binaries to source control, but we need to ensure everyone’s on the same version.
It seems like a common consideration, but I haven’t found any good articles addressing the issue specifically. Does anyone know of a best practice we can use for this? Thanks!
If your projects are internal, you can just add the common projects to your solution and add project references (rather than ordinary assembly references) to the projects that use them. Assuming that your build time issues are coming from the fact that you have a great number of common projects and each individual solution would only use a few, this should mitigate the impact.
If your issue is that you need to ensure that project
Xand projectYare both using the same version of your common library, then referencing the binary (and storing it in source control) is your best approach. Build times are not something that can really be addressed by changing approaches, unfortunately.As to what pattern to follow in source control, you’ll need to tell us what product you’re using.