Does your solution have one or more Z folders in the App_Config/Include directory?  The answer is probably yes.  And in those folders are probably some files that start with a Z.  Most of you know why:  Sitecore loads config files in a folder first, then recurses down the folder chain until it’s done.  That’s the “preferred” method according to Sitecore.

I think we can do better, though.  I was thinking this through while sitting in the airport due to a delayed flight.  It could be done, but it would require a little more tweaking than I think some Sitecore devs are accustom to.  But that’s ok, right?  No pain, no gain.

Enter in the Sitecore Config Deferrer.  It’s a simple concept really.  Allow config files to not be processed in alphabetical orders.  Allow them to be processed in an order that makes sense for your project.  90% of the time this isn’t an issue, but for that 10%, adding Zs or folders to affect the logic is a bit clunky. Again, we can do better.

So here’s the solution I came up with.

Take a set of config files.

From a config in your App_Config/Include/Folder/PatchFolder.config:

From the root of your App_Config/Include/PatchRoot.config

Nothing too complicated there.  They both are competing for the same setting.  In the “files first, folders second” default behavior, the output would look something like this:

That makes sense.  We see that all the time.  That’s why zSwitchMasterToWeb.config is in a zzz folder.

Now we can look at a simple configuration file added to our project:

With this file in place, this is our output:

Did we change any of the files in the Includes folder? Nope.

Here’s how we do the magic:

In the web.config, there’s a configuration section.  This configSection is responsible for loading all the includes and applying the patch process at startup:

Notice the first section there.  It tells Sitecore that for loading this section, use the default ConfigReader.  This reader does exactly what we know it to do. Parse all files/folders and apply patches.  This is what we need to change to add in the ability to defer configs.

Here’s a look at the LoadAutoIncludes method that ships with Sitecore. I’ve highlighted the additions.

The call to the ProcessDeferrals is the only new item in this method.  We’ll talk about him later.  The real meat of this code comes inside the overloads where you pass in a path and patcher:

The first part is there to initialize our list of deferred files.  This is a relatively simple method:

Read in the XML, iterate through the File items, resolve to absolute paths, and be done with it.

The next step is to actually skip the files.  If we find a file while we’re trying to iterate all folders/files, then we just skip it.  Easy enough.

Finally, all those files that were skipped need to be applied.  That’s our ProcessDeferrals method.  It does even less than you think it would:

That’s it.  All that’s left to do is patch in the web.config manually.  We can’t do this automatically, unfortunately. You need to touch the web.config by hand.  It’s ok though, I promise.

To summarize, we do the following:

  1. Update our web.config to point to the new Reader
  2. Initialize our deferral list.
  3. Iterate through all files/folders like normal.
  4. If we find a file to defer, skip it.
  5. Process all deferred files.
  6. ???
  7. Profit.

I’ve posted the source for this solution out in bitbucket: https://bitbucket.org/RAhnemann/deferringconfigreader

If you have any questions or run into any issues, please let me know!

-Rob

Facebooktwittergoogle_plusredditlinkedinmail