1

How have others solved the problem of assembly hell in Helix? I am facing this issue in a current client and looking to for ideas on how to solve it. I have my own ideas but would like to hear other ideas.

The Problem:

The Helix architecture is all about creating separate projects to eliminate dependencies. However, in the process, it seems you might run into the old DLL Hell problem.

By this I means that let's say you have 10 different foundation project, and maybe 20 different feature projects, and another 10 or so web site projects. All of this will eventually get deployed into a single /bin folder. Some of these projects may need newer package references than others. When all of this goes into the single /bin folder, you need to use the newest version of any given assembly. And of course, make sure your web.config file has the assembly redirection set upright.

My Question:

How have others solved this problem? If a project needs a newer version of a NuGet package, do you find all references in other projects and update those? Do you use special deployment scripts? Other techniques, PowerShell scripts or tools?

  • 1
    Put all projects in a single VS Solution. Helix is not about packaging or deploying separately. Its about dependency flow. – Richard Seal Jan 28 at 21:40
  • I always ensure that I've used the Nuget Consolidate option to keep all references the same version and I generally quarter back the entire Build/Deploy process using a single "All" project layer project which references every single project I want to deploy so I can just run MSBuild on one project (makes it quicker) and also means you can keep your Nuget package references all aligned in this project (and therefore the web.config dll redirects) in this project's web.config – Dave Goosem Jan 29 at 1:23
3

One way to solve this is to use SDK project format for your Visual Studio projects. Besides other benefits it has a feature called Central Package References which allows you to have a single place in solution where you manage versions of your Nuget packages. In this setup your individual projects only refer to Nuget packages by name and do not specify a version.

For example, this is how our project files look like:

<Project Sdk="Microsoft.NET.Sdk">
  ...
  <ItemGroup>
    <PackageReference Include="Sitecore.Kernel" />
    <PackageReference Include="NewtonSoft.Json" />
  </ItemGroup>
  ...
</Project>

And this is excerpt from our central package references file:

<Project>
  <ItemGroup>
    ...
    <PackageReference Update="Sitecore.Kernel" Version="9.0.180604" />
    <PackageReference Update="NewtonSoft.Json" Version="9.0.1" />
    ...
  </ItemGroup>
</Project>

This helps us to ensure that all Helix modules have the same versions of Nuget packages.

You can read more about using SDK project format in Sitecore solutions here: https://blog.vitaliitylyk.com/sdk-project-format-for-sitecore-solutions/

| improve this answer | |
  • That looks like a great way to solve the problem. I will have to make sure the rest of the team has the right VS version (15.6). I do not, but that should be a problem easily solved. – Gary Williams Jan 29 at 17:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.