Shooting yourself in the foot with a config patch – redux

Sitecore’s config patch files are great. But sadly it’s entirely possible to cause yourself headaches with them. I’ve written before about how it’s possible that small typos can cause big issues. In that style, a colleage brought an issue to me recently which was an interesting new variation on this fun…

The issue…

After a deployment of a small change, a site had blown up with an odd error message. It wasn’t exactly this, as the object being referenced was different, but it was very similar to:

[InvalidOperationException: Could not find property 'patch:delete' on object of type: Sitecore.Pipelines.Loader.DumpConfigurationFiles]
   Sitecore.Configuration.DefaultFactory.AssignProperties(Object obj, Object[] properties) +2343
   Sitecore.Configuration.DefaultFactory.AssignProperties(XmlNode configNode, String[] parameters, Object obj, Boolean assert, Boolean deferred, IFactoryHelper helper) +622
   Sitecore.Configuration.DefaultFactory.CreateObject(XmlNode configNode, String[] parameters, Boolean assert, IFactoryHelper helper) +320
   Sitecore.Configuration.DefaultFactory.CreateObject(XmlNode configNode, Boolean assert) +68
   Sitecore.Pipelines.CorePipelineFactory.GetObjectFromType(XmlNode processorNode) +91
   Sitecore.Pipelines.CorePipelineFactory.GetProcessorObject(XmlNode processorNode) +145
   Sitecore.Pipelines.CoreProcessor.GetMethod(Object[] parameters) +132
   Sitecore.Pipelines.CorePipeline.Run(PipelineArgs args) +455
   Sitecore.Pipelines.DefaultCorePipelineManager.Run(String pipelineName, PipelineArgs args, String pipelineDomain) +22
   Sitecore.Nexus.Web.HttpModule.Application_Start() +288
   Sitecore.Nexus.Web.HttpModule.Init(HttpApplication app) +670
   System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers) +570
   System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context) +169
   System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context) +372
   System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext) +329

[HttpException (0x80004005): Could not find property 'patch:delete' on object of type: Sitecore.Pipelines.Loader.DumpConfigurationFiles]
   System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +525
   System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context) +118
   System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context) +708

The deployment included a change to a config patch file. With all the noise stripped out it looked something like:

<configuration xmlns:patch="">
        <processor type="Sitecore.Pipelines.Loader.DumpConfigurationFiles, Sitecore.Kernel">

(Again, ignore the specific pipeline processor being adjusted here – this is just a convenient example to reproduce the bug without including any client-specific noise)

Cue a load of head scratching, because at first glance, that looks fine, doesn’t it?

The issue…

This is a great example of the answer being well described by the error message, but in a way that is initially confusing.

It took me a few minutes to cotton on to this, but what that exception is saying can be translated as “What’s that <patch:delete/> thing? It’s not a property on the DumpConfigurationFiles object that I can set, so what should I do with it?

Well it’s supposed to be a config patching directive, which is defined by the “patch” namespace in the XML document. So if the XML processing for the config patch file can’t work out what’s going on, that suggests something wrong with the namespace…

Spotted it yet?

Yup. There’s a trailing slash missing.

A valid config patch file starts with:

<configuration xmlns:patch="">

but what we have is:

<configuration xmlns:patch="">

Put back that one missing character and the issue goes away…


Take care with your patch files. It’s surprisingly easy to introduce a small and difficult to spot mistake, that can take time to detect. In this case, it turns out that the dodgy patch which cause the issue had been copied from a Community Site post – so it pays to check patches you copy off the internet before you try to deploy them…


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s