A better way to track down violations of helix design principals, resulting in Fewer projects and faster build times

The Sitecore Helix Framework

Sitecore released the Habitat project in early 2015; it's an implementation example that uses the Helix framework. One of the major complaints about Habitat was the large number of projects, which can make managing and compiling the Habitat solution difficult.

The large number of projects, however, helps enforce the Module inheritance rules specified by Helix; by separating each module into its own project, cross module dependencies become more obvious. If a better way can be found to track down violations of the Helix design principals, some of the components in a typical Helix implementation can be combined, resulting in fewer projects and faster build times.
FxCop Rules for Sitecore Helix

Five Simple

FxCop Rules

By adding 5 simple rules, FxCop can ensure that Helix design principals are adhered to. Following the naming convention for Helix namespaces, FxCop rules can be constructed to make sure modules aren’t referencing components in violation of the Helix rules listed above. The rules are:

  • ScHlx001 – Validate Helix Projects do not access other Projects
  • ScHlx002 – Validate Helix Feature do not access other Features
  • ScHlx004 – Validate Helix Features do not access Projects
  • ScHlx005 – Validate Helix Foundations do no access Projects
  • ScHlx006 – Validate Helix Foundations do not access Features
FxCop rules Ensure projects are following the 
High Cohesion and Low Coupling Pattern
These FxCop rules were created to allow developers to reduce the number of projects in the Habitat implementation while sticking closely to the Helix architecture. We feel these rules enable developers to more easily follow the design pattern of Sitecore Helix.

Let’s Work Together

When it comes to experiences we know how important it is to drive results.

Contact us today to get started.

Top Row
Middle Row
Bottom Row