.Net Solutions with Complexity

.Net Solution builds can get complicated with multiple solution files

We often get customers who have multiple .Net Solutions for creating a single application.   While Microsoft may advise against the practice, large companies tend to push the limit in software development requiring that more than one .Net solution file be used.  The .Net IDE cannot handle this requirement, which is were we come in.

OpenMake Meister can support the building of multiple .Net solution files, treating them as one big .Net solution file.  By doing this it resolves all cross solution dependencies delivering incremental builds and deploys, and accelerated .Net builds using parallel build processing.

If you need to execute a full build of multiple solutions in Meister, you simply use the .Net plug-in to create a Meister Target file for each .Net Project in the solution.  Meister will then generate a build control file that contains all projects for all solutions.  It uses MSBuild to execute the compile/link, but it manages the dependencies, incremental processing and parallel builds across the projects.

For companies who are doing large .Net builds with multiple solutions, we have seen speed improvement of up to 50% over what other build management solutions can offer such as IBM UBuild. These solutions cannot do incremental builds or build in paralell. What they do instead is have you write Nant scripts, break up the solution compiles onto different machines, and build circular until you have come to the end.  Not very efficient, but the best that can be done without doing any type of real intelligence work on the dependencies.  Products offered by Electric Cloud cannot help with this type of problem as well.  They depend on the use of GnuMake or old Nmake files that are not used by the .Net framework.

So the good news is there is a strong solution for managing multiple solution .Net files.


multiple .Net Solutions as one build

Complex .Net Solution Builds


Ms. Ragan has had extensive experience in the development and implementation of DevOps for large organizations. She began her consulting career in 1989 on Wall Street specializing in build, testing and release management for the distributed platform. It was during her consulting experiences that Ms. Ragan recognized the lack of standardized development procedures on open systems that were common on the mainframe. In the years leading to the creation of OpenMake Software she worked with development teams in implementing a community driven standardized build and deploy process that enabled frequent builds and releases, automated around version control. Her knowledge and experience contributed to the creation of OpenMake Meister, the first commercial Build Automation solution. Ms. Ragan served on the Eclipse Foundation Board of Directors as an Add-in Provider Representative for 5 years. She has been published on numerous occasions and regularly speaks at conferences including CA World where she presented for 15 consecutive years. She holds a BS Degree in Business Administration, Computer Technology from California State University, Pomona.

Related Posts


Build Environment Variables

Build Environment Variables and how to manage the details Build Environment Variables are part of the build process Build Environment Variables are critical, detailed pieces of the over build process. If you are using OpenMake Read more...


Distributed builds and Configuring Remote Agents

Distributed Builds and Remote Agents Using Distributed Builds with Remote Agents for Continuous Integration Distributed builds requires the use of Remote Agents.  A common question I see on our support forums is how to configure Read more...


Incremental builds – critical to Continuous Build

Incremental Builds are critical for fast continuous build Making Incremental Builds real Incremental builds are important for managing continuous build for continuous delivery. Handing over a release from dev to prod must be easy and Read more...