Home > SSW Standards > Rules > SSW Rules to Better Large Builds in Visual Studio.NET
Do you agree with them all? Are we missing some? Let us know
what you think.
Desired Features of Structuring Large
Builds in VS.NET
Scalable - The project should allow continuous additions to
- Developers should be able to keep adding to the
- Multiple Versions - The project should support multiple product
- The structure should be able to allow developers to
work on the next release while there is still work in
progress for a previous release of another section of
- Developers can work side by side with different
versions in parallel (i.e. at the same time)
- Efficient - The build should be as quick as possible.
- Reliability - Builds should be reproducible on any
machine and reliable.
- Switchable - The project should be able to switch between debug
release and other versions.
- The project should be able to activate without
- A config should be made for a demo build.
- It should support a full release.
Method #1 - Using Project Reference Assemblies within VS.NET
The first attempt was the following method of adding project
references to a large solution.
Figure: Adding a project reference
Each project within a solution references other product's
assemblies by the project's GUID.
The advantages of adding the project to the solution is that
you can easily switch between debug and release versions, and the
build time is quicker.
The main disadvantage is that the project can only reference other projects within the same
Method #2 - Using File Reference Assemblies within VS.NET
The following method of adding file references to a large
solution was also attempted.
Figure: Adding a file reference
This method involves projects referencing assemblies by looking
into their reference path.
The main advantage of
referencing .dll's is that it is more flexible. Projects can reference assemblies from other solutions
outside the current solution.
- The solution's environment is "cleaner", allowing projects
to be more expansive.
- All you need to do is change the assembly to "shared".
There are, however, many disadvantages
including the fact that only one version of the proj file can be
added to the solution.
- The .csproj file cannot be used.
- You cannot reference or one set of
assemblies for debug and another for release. Only point to one.
- VS.NET only use the paths specified in the .proj file as a hint.
VS.NET records the location of the assemblies as options for the
project for each user.
- You cannot switch between versions.
- You also cannot use this method if there are 200 projects in one
Scenarios of building the system
Figure: The common scenario of a Large Project
- First option would be to put all the projects in a single solution, reference projects using
Figure: Option #1 All projects in one single solution
Putting all the projects into a single solution and reference the
projects using project references has the following advantages and
The main advantage of
having project references is that it can support multiple versions quite
- Other advantages include the fact that it can be a lot more
reliable and switch-able.
There are, however, two major disadvantages
in adding many projects to one single solution.
- It is not scalable. Having 240 projects would take 1 hours and
30 minutes to load and to build in one solution, so it can be very
difficult to allow that kind of a solution to continually grow.
- Middle tier could possibly have 100's of IP addresses.
- It is not efficient to load that entire time as mentioned above.
In general one solution can efficiently handle 60 projects.
- Another option would be to create separate solutions for each application.
i.e. Have a Windows Solution, a separate ASP.NET Web App Solution etc.. each solution referencing the middle tier and base system projects.
Figure: Option #2 Every application with its own solution
The main advantage of
having separate solutions for each application is that there will be
less load time than the 1st option mentioned.
- Multiple versions can also be supported.
- Switching between debug and release is relatively easy.
The fact that the
application is being build 4 times would make build time significantly
longer. Other problems include:
- Applications trying to load versions which could change during
the build time. However this could be worked-around by not allowing
auto-increment of the Assembly info Version Number.
i.e. instead of "2.0.*", removing the star ("2.0") will prevent
increments of the version number.
- It is not efficient repeating the build in each solution as
- It is not scalable, or reliable.
If there are no signed assemblies, make sure there are dynamic
assemblies. The application must be build once so there are no differing
versions of these assemblies. The contents of exactly what's in each
assembly must be known.
- Mick's Recommended Approach
Figure: Option #3 Using Staging Areas
The recommended approach
- Each project goes into a single solution.
- This is determined by grouping projects depending on the
- The Data Access solution is build first, then the Middle
Tier depends on the first solution. Applications depends on
- Developers don't want to change too much, so these layers
should be kept invisible from them.
- Each solution references assemblies from a single staging area.
- Developers don't need to look at the data access. The
applications will get the assemblies directly from the staging
- Assemblies found in the staging area are only locked when
the underlying layers are being rebuilt.
- Staging areas are mapped to a drive letter using the dos command
"Subst" or a network share.
- Mapping to the path is more flexible in gaining access to
the staging area and modifying it.
- Instead of having long paths, it is recommended to have one
drive letter regardless of the version. This would allow
switching between debug and release easier, as well as switch
- File references are solved with having the same drive
- These drives that are mapped are made by scripts that are
run. The script also includes putting the files straight into
$ log:$ [- SourceSafe Admin]
expand keyword "*.cs" "*.vb" "*.xml"
- There would also be a set of macros that are specificly
Clean the proj.
Clean the sln.
- Create solutions which group projects by there dependencies as
- Each project is only built once, speeding the build and eliminating problems with versioning between .NET assemblies.
- Referencing from a single drive letter helps simplify the problems with using file references
- The use of "subst" and mapped network drives allows flexibility of easily the location from which a solution is referencing its assemblies.