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...
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="http://www.sitecore.net/xmlconfig"> <sitecore> <pipelines> <initialize> <processor type="Sitecore.Pipelines.Loader.DumpConfigurationFiles, Sitecore.Kernel"> <patch:delete/> </processor> </initialize> </pipelines> </sitecore> </configuration>
(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?
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="http://www.sitecore.net/xmlconfig/">
but what we have is:
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig">
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...
↑ Back to top