Sitecore 7 Update-2 and Synthesis 6

Sitecore 7 Update-2 was released today, and it brought with it a surprise: Synthesis’ LINQ query support broke. Well, that’s unusual for a Sitecore update.

Fortunately it is easy to fix. In the Sitecore.ContentSearch.Lucene.DefaultIndexConfiguration.config config patch file, Update-2 changes all of the element casing from PascalCase to camelCase. So the old XPath /configuration/sitecore/contentSearch/configuration/DefaultIndexConfiguration turned into /configuration/sitecore/contentSearch/configuration/defaultIndexConfiguration. DOH! Unfortunately for us, XML - and Sitecore config patching - is case senstive. This means the config tweaks made to search in Synthesis.config no longer applied!

The release notes for Update-2 do not mention this casing change, so if you were manually patching you might not catch this. But the stock DefaultIndexConfiguraion.config file available for download on that page, as well as in the zip distro of Update-2, both change a lot of case in the config.

Fixing the problem

Fortunately it’s pretty easy to fix Synthesis running against a re-cased Update-2 config file. At the bottom of your Synthesis.config find the section and replace it with this (or just change :

            <indexDocumentPropertyMapper type="Synthesis.ContentSearch.SynthesisDocumentTypeMapper, Synthesis" />

            <fields hint="raw:AddComputedIndexField">
                <field fieldName="_templatesimplemented" storageType="yes" indexType="untokenized">Synthesis.ContentSearch.ComputedFields.InheritedTemplates, Synthesis</field>

Dealing with versioning

Unfortunately this leaves Synthesis in a less than optimal situation where the default distribution is more or less Sitecore patch-specific. Synthesis 5, released with Sitecore 7 RTM, only works with RTM. Synthesis 6, released with Update-1, only works with Update-1 due to the moving of a Sitecore class in the update. It requires you to find this blog post to get it to work correctly with Update-2 by way of the patch above. The upcoming Synthesis 7 will have configuration by default for Update-2 - which means it will break if installed under Update-1.

Don’t get me wrong, I love Sitecore 7, but the search APIs are more than a little unstable at the moment for library authors!

Synthesis 6 released

Synthesis 6.0.0 has been released to the NuGet gallery. Despite the lofty sounding version bump, this is just a case of SemVer because Sitecore 7 Update 1 moved a class (IndexField) between assemblies. This means binary distribution of Synthesis for Sitecore 7 RTM will not work with Update 1, and distributions for Update 1 will not work with RTM. Joy!

Only upgrade if you’re using Sitecore 7 Update 1!

New things in 6.0.0:

  • Fixed an issue where unpublished fields could cause NullReferenceExceptions when accessing HasValue in weird ways
  • Added the ability to customize the interface suffix on generated interfaces
  • Compiled for NuGet against Sitecore 7 Update 1

Announcing the release of Synthesis and Blade

For years at ISITE Design we’ve been inventing ways of making Sitecore development easier and more fun. Today I’m happy to announce that some of those tools we’ve been using internally for ages are now publicly available for everyone to use.


Synthesis is an object mapping framework that automatically generates strongly typed C# classes to represent your Sitecore templates. While this sort of library is nothing new in Sitecore circles, Synthesis brings some unique features to the table:

  • A universal object interface for Sitecore 7. The same generated objects that work in database queries also work great in LINQ against an index. If you access data that isn’t in the index, they’ll even transparently load the item from the database for you.

  • Automatic LINQ query filtering. You won’t have to remember to filter by template, language, and version when you query LINQ with Synthesis.

  • Generation of an interface hierarchy to represent template inheritance. This brings a whole world of power to you by enabling you to write polymorphic renderings. Nearly all of your interaction can be done by interface.

  • Automatic checking to see if your generated classes match what’s defined in Sitecore

  • Extensible field API allows you to automatically map custom field types onto a strongly typed version of themselves. Ever dealt with custom XML fields before? This makes them awesome.

All of the other expected features of an object mapper are also available, such as:

  • Full support for Page Editor

  • Support for standard field types such as images, multilists, and rich text fields

In Action

There are some examples of using Synthesis on the GitHub page.

Getting Synthesis

Synthesis is available now on NuGet for a one-click install. You can also see the source on GitHub, or review the documentation.

Which NuGet package should I download? For installing into a web project, use the Synthesis package - it comes with configuration files. If you’re referencing it from a library, use the Synthesis.Core package which is binary only.


While Synthesis handles the mapping side, Blade handles making renderings awesome and has some nice integration points with Synthesis.

Blade uses the MVP pattern to allow you to create very DRY, single-responsibility renderings, allowing you to focus on presentation code and not data access. With Blade, your renderings only request the type of model they expect. For example:

public partial class SampleSublayout : UserControlView<MyViewModelClass>

Then Blade steps in and maps the model type onto a Presenter class, which defines how to supply the model type. For example:

public class SamplePresenter : SitecorePresenter<MyViewModelClass>
    protected override MyViewModelClass GetModel(IView view, Item dataSource)
        var model = new MyViewModelClass();
        model.Example = dataSource.DisplayName;

        return model;

This enables simple isolation of both views and presenters for writing testable frontends, and looser coupling even if you aren’t testing. Don’t worry, not every rendering needs a presenter. If you’re just using a model type from a Sitecore object mapper such as Synthesis (via the Synthesis.Blade package), Glass, or Compiled Domain Model, you can make that automatically map to the data source item without defining an explicit presenter.

Ubiquitous Razor 2 Support

Blade also brings first-class support of the Razor 2 templating language into Sitecore, without using the Sitecore MVC functionality. This is advantageous when developing sites that use modules that are not compatible with the Sitecore MVC rendering technology - you can reap the benefits of MVC-style renderings without the hassle of implementing renderings twice or resorting to XSLT. A Razor rendering with Blade works exactly like a sublayout - only the path is to a cshtml file instead of an ascx. There are also many useful helpers included that simplify things like rendering dates, images, and controlling page editor functionality. For example:

@inherits RazorRendering<MyProject.MyViewModelClass>

@Html.TextFor(model => model.SitecoreDataField)

Blade does its best to feel as much as possible like Sitecore as well as ASP.NET MVC, so it doesn’t require digesting lots of unfamiliar ways of doing things. Sitecore features such as Page Editor are fully supported. MVC conventions like automatic HTML encoding, partial views, anonymous types defining HTML attributes, and relative view referencing are all there.

Awesome Rendering Diagnostics

Ever spent an hour figuring out why a rendering was busted, only to realize it was output cached without you realizing it? What about having to find a rendering file for a HTML/CSS dev so they can make markup changes? You’ll love Blade then. Blade’s rendering types emit HTML comments that indicate where a specific rendering begins and ends, as well as if it was output cached, when, and what the cache criteria were. The comments disappear when dynamic debug compilation is disabled, leaving production sites pristine.

Check this out:

<!– Rendering was output cached at 5/16/2013 9:31:42 PM, ClearOnIndexUpdate, VaryByData, VaryByQueryString –>

<h1>Hello, world!</h1>
<!– End Rendering ~/layouts/Sample Inner Sublayout.ascx, render took 0ms –>

Full Sitecore 7 Support

Blade supports the enhancements made to renderings in Sitecore 7. It supports renderings that decache on index update, have multiple items as data sources, index-query based data sources, and even defining your own data source resolution logic. Even better, it removes boilerplate code by automatically normalizing all kinds of data source specifications back into simple Item (or Item[]) instances.

Getting Blade

Blade is available now on NuGet (and its Synthesis integration package) for a one-click install. Make sure you have Sitecore Rocks configured and connected before installing Blade as it uses Sitecore NuGet to install some supporting items. You can also see the source on GitHub, or review the documentation.

Which NuGet package should I download? For installing into a web project, use the Blade (and/or Synthesis.Blade) package - it comes with configuration files. If you’re referencing it from a library, use the Blade.Core (and/or Synthesis.Blade.Core) package which is binary only.


I’d love to hear what you think about these libraries or answer questions about them. Feel free to comment below, submit issues on the GitHub repositories (bonus points if there’s a PR attached!), tweet @kamsar, or yell “hey you!” over the back fence.