4.2. Alternate Visual Studio Solution Structures¶

4.2.1. Are you solving the right problem?¶

If slow builds or the overhead of creating new Visual Studio projects are the main concern with the conventional Sitecore Helix project architecture, you might first consider whether misapplication of the Sitecore Helix Practices is actually the root of the issue, or whether better tooling might resolve the concern.

4.2.1.2. Does your solution contain projects you do not need?¶

Does your solution contain empty unit test projects for one or more modules? This might be the case for simple modules which only contain configuration and/or View renderings. These add no value and unecessarily slow down your builds.

The same applies for TDS projects with no items. If these exist only to build/deploy a module, consider a single build-only TDS project with multiple Source Web Projects.

Sitecore Helix Examples

The TDS version of Helix Basic Company uses a single TDS project for file copy / packaging, and additional TDS projects as-needed within each module. It also only has test projects for modules with testable logic.

gulp.task("Publish-All-Projects",
    function(callback) {
        var msbuild = new _msbuild(callback);
        msbuild.solutionName = config.solutionName + '.sln';
        var overrideParams = [];
        overrideParams.push('/p:Configuration=' + config.buildConfiguration);
        overrideParams.push('/p:DeployOnBuild=true');
        overrideParams.push('/p:DeployDefaultTarget=WebPublish');
        overrideParams.push('/p:WebPublishMethod=FileSystem');
        overrideParams.push('/p:DeleteExistingFiles=false');
        overrideParams.push('/p:publishUrl=' + config.websiteRoot);
        overrideParams.push('/m');
        overrideParams.push('/restore');
        msbuild.config('overrideParams', overrideParams);
        msbuild.config('version', config.buildToolsVersion);
        msbuild.build();
    });

4.2.2. The role of Visual Studio projects¶

Aside from the pragmatic issues, the architectural question at the root of this decision is the role of a project/assembly in Visual Studio. This is essentially the subject of Robert C. Martin’s Principles of Package and Component Design, which contain the underlying principles that Sitecore Helix is based on. Based on these principles, Visual Studio projects form a “physical” boundary and unit of change for modules in Sitecore Helix.

Martin however makes an assumption that modules (packages) are released / deployed independently. Due to the versioning and testing complexity this would put on the typical Sitecore solution, Sitecore Helix actually discourages partial deploys of modules, meaning that the unit of release is the entirety of the application. While modular deployment may be a requirement for some very large solutions, if you are not deploying and versioning these assemblies independently, it is a valid question as to whether the modules really merit their own Visual Studio projects.

The modular architecture practices of Sitecore Helix though are meant to improve solution maintainability and dependency management. It’s easier to track and manage the dependencies to and from a module, as they require an explicit project reference by the developer. While these are easy enough to add, is an additional step and something that could be easily flagged in a code review.

The convention of using a separate web application project for each module (which deploys to Sitecore CM/CD) also means that all the code and configuration related to a module are located in one place. Combine that with the module filesystem and solution folder structure, and you also have the items, tests, and other related code for that module. Practically, it’s very easy for a future developer to find/discover the code related to a desired system change.

It is true that FxCop rules can be used to enforce Sitecore Helix dependency rules without separate projects, effectively giving you a “logical” boundary between modules to help enforce dependencies. However the loss of physical Common Closure and the potential maintenance impact should still be considered when taking this approach.

4.2.3. How to structure when consolidating¶

How you consolidate the projects in your solution will ultimately depend on the issue(s) you are attempting to address, and your view on the purpose and role of Visual Studio projects.

• When using Sitecore TDS, you could consolidate just your TDS projects into a smaller number of per-layer, per-database projects. This approach has been used successfully by Sitecore (former Hedgehog) services teams.

  • Foundation.Master
  • Foundation.Core
  • Feature.Master
  • Feature.Core
  • Project.Master
  • And potentially an additional TDS project for consolidating/packaging all items.

• You may group Features into combined projects based on the concept of Feature Groups. This will reduce the number of projects but care must be taken to avoid dependencies between Features in a group. A Feature Group is merely a logical grouping of modules and does not affect Sitecore Helix conventions around Feature-to-Feature references.

• You may place an entire Layer into its own project as a “logical” grouping of modules. This benefits the Feature Layer most, as it should contain far more modules than other layers. Consolidating the Project Layer likely provides little benefit due to the number of modules, and may create confusion around the composition of each Project Module. You should take care when consolidating the Foundation Layer as well, as the allowance for Foundation-to-Foundation references means that these dependencies need to be closely monitored and managed.

• You can place all the code for a single deployment target (e.g. main Sitecore website CM/CD code) into a single assembly. This would be the most extreme example of treating a Visual Studio project as a unit of deployment. Your boundaries between Sitecore Helix modules becomes entirely logical, and Common Closure is lost to a large degree.

• You can split out modules as needed for reuse. This could be a requirement in organizations with multiple Sitecore deployments and a common shared code base. However in this case you likely should be independently managing and versioning these modules, and distributing them to other solutions via NuGet.

In all of the approaches above, you will need to consider the structure of your tests, serialized items, and projects for additional Sitecore services as well. At the very least you should aim to retain the “logical” boundaries betweeen modules by mirroring the filesystem and namespace structure within each of these.

It’s strongly recommended that you use tools such as FxCop rules and Sitecore TDS Validation to enforce dependency rules between your modules if you consolidate Visual Studio projects in any way.

4.2.4. Does Sitecore Helix really allow this?¶

Sitecore Helix is not a rulebook. You should be pragmatic about applying its conventions rather than religious. When deviating from them however, you should always:

• Understand why, understand the positive and negative impact of doing so, and anticipate the technical debt you may be accumulating.
• Document the deviation and alternative convention(s).
• Ensure you are still striving for maintainability and long-term value.

4.2.5. Consolidated Projects Example¶

Sitecore Helix Examples - TDS Consolidated

The consolidated version of Helix Basic Company demonstrates the extreme example of using a single web application project for the entirety of the solution.

Figure: Solution structure for Helix Basic Company - TDS Consolidated

Note that additional projects are needed for tests and serialized items. A consolidated structure with Unicorn would similarly need a separate filesystem location for all serialized items. Also notice that even within the Web project, the module configuration files are intermixed.

It is ultimately the responsibility of the Solution Architect to weigh this loss of “Common Closure” and potential maintenance impact, vs potential improvement in build times, deployment, etc.