What if I were to tell your the Sitecore.Kernel dll from NuGet isn't the latest??

Sitecore has a knowledge base full of patches and updates that we need for our environments.  One that I ran into recently, after a minor version upgrade, reminds me that how we patch our sites is really important. First let's start with the error, it's important too.

In Sitecore 8.2 Update 6 and 7 as well as 9.1 Update 1 the kernel has a bug that crashes on a bad internal link. Sometimes this just crashes the Rebuild Link Database application. But other times it can just bring down your whole site.

If you don't have proper error catching and you are gathering links for any part of your navigation. When Sitecore goes to resolve a link it can crash deep inside of the kernel code. Being that it is a link issue, you could rebuild the links database, but that is broken too. The error looks like this:

Exception: System.FormatException
Message: Unrecognized Guid format. Actual value:
Source: Sitecore.Kernel
at Sitecore.Data.ID..ctor(String id)
at Sitecore.Xml.Xsl.LinkUrl.GetInternalUrl(Database database, String url, String itemID, String anchor, String queryString)
at Sitecore.Xml.Xsl.LinkUrl.GetUrl(XmlField field, Database database)
at Sitecore.Data.Fields.LinkField.get_InternalPath()
at Sitecore.Data.Fields.LinkField.get_TargetItem()
at Sitecore.Xml.Xsl.LinkRenderer.Render()
at Sitecore.Pipelines.RenderField.GetLinkFieldValue.Process(RenderFieldArgs args)

Nested Exception

Exception: System.FormatException
Message: Unrecognized Guid format.
Source: mscorlib
at System.Guid.GuidResult.SetFailure(ParseFailureKind failure, String failureMessageID, Object failureMessageFormatArgument, String failureArgumentName, Exception innerException)
at System.Guid.TryParseGuid(String g, GuidStyles flags, GuidResult& result)
at System.Guid..ctor(String g)
at Sitecore.Data.ID..ctor(String id)

The fix is a patch from Sitecore. And more than a patch, it is a complete replacement for the Sitecore.Kernel dll. That is a deep fix.

This brings up the point of how to we patch this? Most of us use Sitecore NuGet packages for our Kernel. This keeps everything where we need it and consistent across all our developers and CI. But Sitecore does not post hot fixes in NuGet. They post the fixes in the knowledge base so that we can pick and choose the fixes we need. You could always upgrade to the latest, but upgrading from 8.2 to 9.1 is a bit a sledge hammer approach. And when you get to 9.1, there are hot fixes there too. Whoopee!

I think the fix has 1 of 2 choices. #1 You can include the new kernel in your builds or #2 ensure that 100% the kernel is not in your build and just patch servers manually. To me #2 has a bit of hope to it. You hope that no one ever includes the OOTB kernel and overwrites your patched dll in any of your environments. You hope to know if they do.

So I think the answer is #1. I like to be intentional in my CI builds. I am doing to my servers what I need done. Every time. I am not letting a snow flake server exist in my environment that has been patched by someone at some time that no one knows about. The utopia we are all striving to achieve is to be able to rebuild your entire production environment via CI scripting. And needing patch files/configs that are not in your build makes that incredibly difficult.

If you follow Thomas Eldblom then you know that he has been speaking about integrating your DevOps into Helix solutions. This means that everything you need to manage an environment is in your helix solution. This includes CI scripts, SIF scripts, PowerShell to build your Azure, etc... I have been experimenting with an Infrastructure.Patch project in my helix solutions. This project has all my patches. Whether they be dlls, configs or just file overrides, this is a project that will patch any site in this solution. And with proper build configurations/transforms you can decide which patch goes where. With this project, I am able to deploy all my patches to all my servers, every time. It also means that when I upgrade, I am able to just delete the contents of this project and start over. This is because your upgrade probably has your patches already in it.

So when it comes to these Sitecore.Kernel patches from Sitecore. I think you need to include these in your build. Whether you add them to a libs folder in your solution or put them on a private NuGet server is up to you. But you want all your environments to be the same. And for all of them to have the proper patches without the need of human intervention.