A few years ago, I wrote about storing Sitecore binaries in an external blob storage service instead of having them in the database. You can read more about it here and the code is available on GitHub. It has several benefits and it works great! I’ve used this implementation in production on large scale solutions for many years.

In Sitecore 9.3, Sitecore introduced its own Azure Blob Storage module, that uses the same principles. Sitecore also slightly changed how databases are configured, so my old module works up to 9.2 as it is right now.

Since Sitecore supports for their own module, it makes sense to use that one instead of running a custom one. However, in true Sitecore spirit, the module was released without testing, so beware of the findings below before using it:

Update: Sitecore have issued a cumulative update to Sitecore 9.3 that addresses the two major faults described in this post. Make sure you have SC Hotfix 415404-1 or later installed.

Sitecore indexes is very powerful for getting various items fast, especially when they are located in various places. There are also some pitfalls that one needs to be aware of. This post covers methods that could be considered in some scenarios. In this post I’ll describe how I reduced indexing time from around three hours down to two minutes for a specific scenario.

There is a dll version conflict for Polly.dll between Sitecore CMP connector and Sitecore Publish Service 4.1.0. The Publishing Service Module comes with Polly.dll version 5.9.0 and the Sitecore Connect for CMP 1.0.0 comes with Polly 6.0.1. This will cause Sitecore CM to stop working during the CMP install, if the SPS module is already in the system.

Update: As Sitecore 9.3 and SPS 4.2.0 was just released a few hours after writing this post, I noticed this applies to that version as well. SPS module 9.3 also comes with Polly 5.9.0.

Update 2: After some help from Sitecore Support and some additional adjustments, I got the following solution to work on my machine:

Keep you 5.9.0 version of Polly.dll in the bin folder. Create a cmp sub folder (bin/cmp) and put the 6.0.1 version of Polly.dll in that folder. Then add the following to your web.config assembly binding section:

<dependentAssembly>
   <assemblyIdentity name="Polly" publicKeyToken="c8a3ffc3f8f825cc" />
   <codeBase version="5.9.0.0" href="bin\Polly.dll" />
   <codeBase version="6.0.0.0" href="bin\cmp\Polly.dll" />
   <codeBase version="6.0.1.0" href="bin\cmp\Polly.dll" />
</dependentAssembly>

I don’t think the 5.9.0.0 binding is really needed, but I found in my logs that the CMP connector was trying to load both 6.0.0.0 and 6.0.1.0.

The easy fix for this is to add assembly redirects into the web.config file before installing the connector and keep the old file: Update: It turned out I tricked myself. I thought I got everything working, but the CMP connector throws exceptions in the log while importing content from Content Hub.

<dependentAssembly>
  <assemblyIdentity name="Polly" /><!-- publicKeyToken="c8a3ffc3f8f825cc" -->
  <bindingRedirect oldVersion="5.8.0.0-6.0.1.0" newVersion="5.9.0.0"/>
</dependentAssembly>

As described in this stackoverflow post, it’s not possible to do assembly redirect between assemblies with different public keys. Polly 5.9 doesn’t have a public key (i.e. it’s null), so at least I couldn’t make binding work to the newer 6.0 version.

As of writing this, I don’t have a solution to this problem. I’m currently awaiting an answer from Sitecore if CMP and SPS can live together or not.

We’ve discovered a rare issue in Sitecore Publish Service (SPS) where it may publish incorrect content to some fields. Even though I think SPS does this wrong, the root cause was inconsistent data in the master database. It turned out such inconsistency exist in most databases, even in a clean Sitecore install.

I just got awarded Sitecore MVP for 2013. Nice! Thank you Sitecore!