While building solutions bases on Sitecore I have to deal also with Sitecore hotfixes. For my current project I already have about 20 different hotfixes. They override default Sitecore files in most cases assemblies and Sitecore configs. I am looking for ways or even best practices how to manage those hotfixes within a solution as well as how to deliver them to a test or production environments.

Currently I keep the files from hotfixes together with my solution. They all are committed to the same code repository. I created a dummy Visual Studio project and added all the files from the hotfixes there. When the dummy project is built together with the solution the hotfix files are copied to output folder and added to a deployment package.

What I miss in this approach it is first of all transparency. I would like to understand why I have each hotfix, what it consists of and how it can quickly be uninstalled without digging too much in Sitecore tickets and knowledge base.

What are you doing with your Sitecore hotfixes? How are they connected to your solutions and CI/CD pipeline?

4 Answers 4


In our project we try to create NuGet packages from them where possible and add them to our own internal feed.

When it replaces an existing Sitecore DLL (for example we've had a hotfixed Sitecore.Kernel.dll) we just use the package from our local feed in every project that requires it.

In case the hotfix adds a separate DLL with a config file to patch it in, we add it to the most relevant module in our Helix solution.

  • I tend to think that this one is the best option that has been suggested so far. Although it requires efforts to create all those nuget packages, it does help to clean solutions and code repositories. It is easy to find all installed nugets/hotfixes, understand what they consist of and uninstall them.
    – i123fr3
    Jun 7, 2019 at 7:01

We are creating one project per each hotfix. We unzip hotfix and put everything into C# project. We create README file (which is not deployed) so we know what each hotfix is used for. We keep also reference numbers and ticket numbers there so we can easily identify them.

During upgrades these projects are checked / validated if are included or not in current version which we are upgrading to and then removed if not necessary anymore.

We have recently created a separate repository for hotfixes with same structure as defined above. We are therefore deploying hotfixes only once or as needed to each environment as we have a special pipeline step in DevOps to either deploy or not this repository.


I have added a new layer to my Helix project called Infrastructure. This layer holds my CI scripts, SIF, PowerShell, DSC, etc.... Everything I need to build my devs and farms. In that layer I created a new Infrastructure.Patch project that I am adding all the hot fixes that the site needs. If need be I am excluding files from being deployed to certainly environments via the build configurations.


What we did in our older projects is edit the MSBuild process of the solution to also copy files from a directory into a build/deploy folder. In this directory it is possible to have several levels of folders, so we had a SitecoreModules folder as base folder which contains multiple folders for each patch or module. In these subfolders there were the App_Config and bin folders and all the files. This might help in getting a structure and some documentation for all the patches instead of combining them all in one VS project, but it might also be considered as a 'nasty' approach..

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.