Check your code with Unicorn serialized data

I was looking into Roslyn recently and figured that it would be useful for checking whether Sitecore ID’s and paths that are used in code are correct or not. I wanted it to check this with the Unicorn serialized data that I have.

That’s why I created an analyzer that does just that. I’m curious to get some feedback on it so I can improve things.

Integrate this into your build using NuGet or use the Visual Studio Gallery to install the extension. Get more info and the source on GitHub (the main page contains installation instructions).

Update: field names and ID’s are now also supported.

Update 2: field names and ID’s can now also be validated against a template.

Update 3: a tooltip will now be displayed for ID’s, to show the full path of the item. Similarly, a tooltip will be displayed for paths to show the ID.

Update 4: fields that are decorated with Glass Mapper attributes can now also be validated against a template.Field on template checking for Glass Mapper

Generating Sitecore code without TDS and with Rainbow

About a year ago, I posted about a way to generate code from your Sitecore data without the need to use TDS. Since then, a new version of Unicorn was released, that supports a new serialization format called Rainbow.

The description on Rainbow’s GitHub page: An advanced serialization and comparison system for Sitecore. Designed for easy merging with YAML-based serialization, and a generic merge/deserialization framework. Works well with Unicorn, or by itself.

Unfortunately, the code generator didn’t support this format. But with a little tweaking, I’ve now added support for it!

You can follow the same instructions as described before. And after that, apply some specific changes to enable Rainbow support.

Happy code generating!

Post content audit messages to Slack from Sitecore

The Sitecore community has certainly embraced Slack. If you want to join your fellow Sitecore developers, be sure to follow the link and get it up and running. It’s great to see so many people from the community sharing knowledge about all things Sitecore in this awesome chat application.

We’ve been using Slack with our team internally at our company as well. And we love having great integrations with our build server, JIRA, Pingdom, Sentry and others (some of which are custom built).

It was about time that we helped our content editors out by providing an integration with Sitecore itself. That’s why I built the Sitecore.Slack.IncomingWebhookForEvents module. Whenever someone edits a content item, publishes or installs a package, others will know about it through Slack!

Follow the instructions on the GitHub page to install this module (using NuGet) for your project.

Monitor your Sitecore server’s health

Having a website up and running reliably requires that you monitor its health. You should always be using a monitoring tool like Pingdom (there are many others). That way, you can get notified when the website is down.

Now, there are several ways of making sure that things are ok at runtime. For example:

  • Sitecore’s HeartBeat.aspx for Load Balancer Health Checks – Standard page in Sitecore that does some limited checks. It’s a good idea to monitor this page.
  • Sitecore Diagnostics Toolset – A desktop application that does various checks to see if your Sitecore implementation is correctly working, with regard to things like security, indexing, performance and scalability. It’s a smart idea to use this tool periodically, but it won’t be helpful for monitoring purposes.

Personally, I like to monitor more than just if a website is up. I also want to know if key parts of the system are functioning properly, like connections to other systems, if certain content is available and if my indexes are ok. These checks may be very specific to my implementation.

That’s why I created a simple drop-in .aspx script that you can easily configure to check these things. You can find it in this Gist on Github. Example output:

It’s quite easy to configure and extend. Just read through the implementation of the Page_Load(…) method. Some more details here:


You’ll want to limit who gets to use the monitoring page, to prevent abuse and prevent hackers from getting details about your implementation. This is especially important if the checks you are doing may impact system performance significantly. Make sure your monitoring tool’s requests to the page match your security settings here.


Adding checks

You can add checks to do when the page is requested by adding them to the ChecksRun collection. Some examples are in the code below. They include checking specific items’ presence in databases and having versions and layout/presentation. They also include checking if search indexes contain enough items, if certain url’s are reachable from the server and if configuration is specified correctly.

It’s also easy to implement your own specific types of checks. Add them to the region “actual checks” as classes that implement the ISitecoreCheck interface (or use the SitecoreCheckBase class).



You may not always want to run the same checks. Perhaps some checks should only be performed at night and some checks may be specific to your DTAP or CM/CD servers specifically. You can use tags to limit which tests are run, as demonstrated in the example below. And then you can specify which tags are applicable by specifiying them |-separated in the url parameter “tags”. The url //SitecoreChecks.aspx?tags=fail would result in the following:


Let me know if you have any questions/suggestions.

Generating Sitecore code without TDS

In the past, I’ve used my own Compiled Domain Model module on projects. It generates wrapper classes based on your Sitecore templates (among other things). But recently, I’ve been working with Glass Mapper.

Glass Mapper doesn’t wrap Sitecore items, but rather maps Sitecore items to objects. The result is somewhat similar; you can work with strong-typed classes/interfaces and extend them if you want.

There are several ways you can configure Glass Mapper. One of the ways is by using attributes. The attributes map the classes/interfaces and their properties to Sitecore templates and fields. This works very well and is very flexible, but it can be a bit tedious to do manually.

That’s why generating the code is a good option. If you’re using TDS, then you can easily generate code.

But if you can’t use TDS (e.g. because of the costs), then here’s a good alternative. Kern Herskind Nightingale did something similar before. But my implementation supports:

  1. Generate individual files for each template
  2. Configure which paths to generate classes/interfaces for
  3. Generate interfaces for Glass Mapper (but it is easily adaptable to other frameworks)

For more information, look at the documentation here, and you can clone/fork the project on GitHub here.

IDog interface example generated using Sitecore.CodeGenerator

IDog interface example generated using Sitecore.CodeGenerator

Sitecore Code Challenge 1

Someone once told me about Pex for fun. And ever since, I occasionally visit the website to solve some C# coding puzzles. Essentially, it requires you to implement some code and have unit tests for it pass. But you don’t know the implementation of the unit tests.

I thought about how we could do something similar with Sitecore, and came up with a way to do it. If you follow the steps below, you’ll have a .sln with a project that compiles and has unit tests. But the tests all fail.

It’s your job to make sure the code passes the unit tests. But the relevant code in the unit tests is hidden inside an obfuscated DLL (can’t be easily decompiled).

The failing assertions  in the unit tests, will give you detailed hints though. And if you succeed in getting the unit tests to pass, your project can be deployed to Sitecore and will actually be usable!

Since this is quite a new way of getting to know Sitecore in a fun way, I’m bringing this to the community as an experiment. I’m very interested to learn your experiences:

  • Are you able to finish the puzzle?
  • Is it fun trying to solve the puzzle?
  • Any feedback for creating a second challenge (if this one turns out to be a success)?

Follow these steps to get started:

  1. Download this ZIP file and extract it.
  2. Copy “Sitecore.Kernel.dll” to the folder “Binaries” (I’ve tested with version 7.2 rev 140526, but it will probably work with other versions as well).
  3. Open the project in Visual Studio and build the project.
  4. Run the unit tests using a runner that supports xUnit (I’m using VS runner, which is free)
  5. The tests are ordered into steps. Go through the steps in  order and look at the reported errors for hints on how to solve the puzzle.

Let me know if you are able to finish this first code challenge! Have fun!

Validating your code references to serialized data

Sitecore developers often need to reference content items from their code. E.g.: a template or branch ID for an import function or reading a global setting that’s stored in the content tree. Using IDs is usually preferred over using paths, because paths may change. It’s considered good practice to keep those ID references in a class with constants, like this:

After recently contributing some serialization logic to Sitecore.FakeDb, I got the idea to write unit tests that validate if these constants have values that are actually in Sitecore. We can use TDS or Unicorn serialized data to validate this.

The following unit test does just that (uses NUnit, FluentAssertions, Sitecore.FakeDb and Sitecore.FakeDb.Serialization):

Just pass in the types (that have Sitecore IDs as static properties) using the “Values” attribute.

But I didn’t stop there. At my company, we’re currently working on a project that uses Glass Mapper. Glass Mapper can use attributes to link mapped classes to the correct Sitecore templates. And in a similar way, properties can be linked to field IDs.

I wanted to validate all those IDs as well, and also check if the field IDs are on the right templates.

That’s why I wrote the following unit test. It finds all the types that have attributes like this and deserializes the corresponding templates. It also checks if the fields are there.

To use it, you need to pass in one type from the assembly that you want to test (or multiple) using the “Values” attribute.

Since I’m quite new to using Glass Mapper, I’d be interested to get some feedback on this. I’m pretty sure there’s more that can be tested.


Unit testing with Sitecore.FakeDb and deserialized data

Recently, I watched the excellent SVUG presentation by Pavel Veller on YouTube. I was impressed by the way Sitecore.FakeDb works. It’s much easier to configure than my FixtureDataProvider, has tighter isolation and is (because of that) much faster.

Even though the syntax for setting up your test data is very easy and short with Sitecore.FakeDb, I think that it can be a lot of work to setup things for a unit test. Besides, those of us using TDS or Unicorn are already putting a lot of information about the structure of items under source control. It would be a shame if we could not use that information.

That’s why I propose a hybrid approach: use DbItem and DbTemplate to setup your tests and where needed, deserialize individual items/templates. This can have the benefit of not having to initialize as much, as well as bringing your serialized data into the test scope.

On that last note: if a template field is renamed and then synchronized with TDS, then if the code you are unit testing relies on that field name… it will fail. Which can be very helpful during development.

I’ve added a project called Sitecore.FakeDb.Serialization to the FakeDb project. It’s usage is entirely optional and adds 2 important classes: DsDbItem and DsDbTemplate (Ds = Deserialized). They inherit from their regular Sitecore.FakeDb counterparts. But instead of having to define the field values, they load them from the filesystem.

You can easily mix these approaches. Here’s an example of a unit test using both:


You can find these changes in my fork on GitHub. To use them, you need to do the following afer you’ve setup Sitecore.FakeDb:
- Add a reference from your unit test project to Sitecore.FakeDb.Serialization.
- Edit the App.config file and add the following section (change the folders to point to your serialized data, or add/remove folders as needed):


Have fun coding!

Index page editor proof pages with Sitecore 7

After competing in the Sitecore hackathon last weekend, I got excited. So when Kyle Heon posted a particular Tweet today, I immediately knew what I would be doing this evening; create a new (small) project on GitHub.

And here you can find the result. Basically, I created a computed field that actually does a http request and downloads the page that you are indexing.

The reason you would want to do this, is because of how content composition in the page editor works. You can add components to a page that reference separate Sitecore items as associated content (a.k.a. datasources). But the content of those referenced items is indexed separately and therefore difficult to search for using Sitecore.ContentSearch (Sitecore 7 search) – if you want ‘pages’ to be the result, like regular site searches usually need.

You can find more information, including installation instructions, on the GitHub page for Sitecore Html Crawler (just scroll down a little).

There are some limitations to this approach that you should know about.

  1. This doesn’t really work well with wildcard items, because they can only be indexed once; not for every item that you want to display on the wildcard item’s page. You would need to change the actual indexer to support that, or handle the difficulty of it in your search query.
  2. I’ve only tested this with Lucene. I think changing the configuration a little could make it work for other providers such as Solr.

Turn any Sitecore package into a NuGet package

I recently posted this idea on Twitter:

And it didn’t take me that long to actually implement it. Follow these steps to turn any Sitecore package into a NuGet package and share it with the world.

  1. Download the CreateSitecoreNuGetPackage.exe file here or build it yourself with the code from GitHub.
  2. Put the files “Sitecore.Kernel.dll” and “Sitecore.Zip.dll” in the same folder.
  3. Create your package in the Package Manager and export the ZIP file.
  4. Run the following command from the command line:
    CreateSitecoreNuGetPackage [PATH_TO_SITECORE_PACKAGE]
  5. Use the NuGet Package Explorer to open the generated  .nuspec file and improve the metadata if needed.
  6. Publish the package to a repository, like

Now, everyone will be able to install/uninstall your package through NuGet. Remember that you need to install Sitecore Rocks and attach your project before installing the package.

Some links to pages that helped me creating this:

I will be very interested to hear your feedback, as I haven’t been able to test this very well. If this utility catches on, I might make a version that you can use from the package manager directly.

Happy NuGetting :-P