SSW Foursquare

SSW Rules to Better Large Builds in Visual Studio.NET - 2 Rules

This category has been archived
Archived Reason: The better ways to manage these builds if by using Clean Architecture and Nuget package manager.
  1. Do you know the desired features of structuring large Builds in VS.NET?

    The desired features of structuring large Builds in VS.NET:

    1. Scalable - The project should allow continuous additions to the structure

      • Developers should be able to keep adding to the structure
    2. Multiple Versions - The project should support multiple product releases

      • 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 the project
      • Developers can work side by side with different versions in parallel (i.e. at the same time)
    3. Efficient - The build should be as quick as possible
    4. Reliability - Builds should be reproducible on any machine and reliable
    5. Switchable - The project should be able to switch between debug release and other versions

      • The project should be able to activate without debug
      • 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.

    ✅ Advantages

    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.

    ❌ Disadvantages

    The main disadvantage is that the project can only reference other projects within the same solution.

    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.

    ✅ Advantages

    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"

    ❌ Disadvantages

    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 solution
  2. Do you know the scenarios for building large .NET projects?

    There are various ways of organizing your code for large .NET projects in Visual Studio.

    Figure: The common scenario of a Large Project

    1. First option would be to put all the projects in a single solution, reference projects using project references.

      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 disadvantages:


      • The main advantage of having project references is that it can support multiple versions quite well.
      • 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.
    2. 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 mentioned above.
      • 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.

    3. Mick's Recommended Approach

      Figure: Option 3 - Using Staging Areas

      The recommended approach

      1. Each project goes into a single solution.
      2. This is determined by grouping projects depending on the dependencies.
      3. The Data Access solution is build first, then the Middle Tier depends on the first solution. Applications depends on both.
      4. Developers don't want to change too much, so these layers should be kept invisible from them.
      5. Each solution references assemblies from a single staging area.
      6. Developers don't need to look at the data access. The applications will get the assemblies directly from the staging area.
      7. Assemblies found in the staging area are only locked when the underlying layers are being rebuilt.
      8. Staging areas are mapped to a drive letter using the dos command "Subst" or a network share.
      9. Mapping to the path is more flexible in gaining access to the staging area and modifying it.
      10. 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 between versions.
      11. File references are solved with having the same drive letter.
      12. These drives that are mapped are made by scripts that are run. The script also includes putting the files straight into source safe. e.g.

        $ log:$ \[- SourceSafe Admin]
        ss option
        expand keyword "\*.cs" "\*.vb" "*.xml"
      13. There would also be a set of macros that are specificly created to:

        • Clean the proj.
        • Clean the sln.
        • Mass Rename.

      Create solutions which group projects by there dependencies as mentioned above.


      • 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.
We open source. Powered by GitHub