Sitefinity 4: Null Reference When Editing Templates

I experienced a "duh" moment today while trying to tackle an error I was receiving while playing with the Sitefinity 4 RC (due out later this week!). Whenever I created a template, I’d always get the following error when I tried to edit it:

Object reference not set to an instance of an object.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.NullReferenceException: Object reference not set to an instance of an object.
Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

[NullReferenceException: Object reference not set to an instance of an object.]
   Telerik.Sitefinity.Modules.Pages.DraftProxyBase.CreateChildControls(Page page) +1804
   Telerik.Sitefinity.Modules.Pages.TemplateEditorRouteHandler.ApplyLayoutsAndControls(Page page, RequestContext requestContext) +196
   Telerik.Sitefinity.Web.RouteHandler.InitializeContent(Page handler, RequestContext requestContext) +475
   System.Web.UI.Control.LoadRecursive() +94
   System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +2759

I kept thinking it was a bug in the RC, or perhaps because I needed to build my project or because it was a Web Applicaiton Project and not a Web Site, as I’m used to working with…

Turns out this was once again another example of my tendency to be a complete bonehead.

Since I was using a free css template (courtesy of STUDIO7DESIGNS) I simply copied and pasted the HTML into my master page. Unfortunately I neglected to replace the <form runat=”server” > tag that is required by ASP.NET master pages to function properly!

Talk about duh. Sorry about that. I’m posting this in case I ever make this mistake again (and God knows, I will), when I search for the answer online, I’ll no doubt find the answer on my own blog!

Sitefinity Development: Targeting Multiple Platforms

As I mentioned in my recent post announcing the Sitefinity Toolkit 1.2, adding support to all of the different platforms and versions for Sitefinity 3.7 was an interesting challenge. In the end it required a total of 22 projects (one for each version/platform) organized into one solution. Today I’m going to walk you through the process I took in setting this solution up.

Sitefinity DLLs

It’s important to note that if you are not doing any kind of deep integration with Sitefinity’s inner core, you will probably never need to setup an elaborate project like this. The multiple projects are only necessary if you are hooking into the core libraries defined in the Sitefinity DLLs and developing a compiled, redistributable library. If you are simply developing a user control, or are developing a library that doesn’t require accessing the internal Sitefinity libraries, then you’re probably fine to keep doing things the way you are.

However, if you are developing a compiled, custom library, you need to be able to reference the Sitefinity libraries in your project by adding the DLL files from the different versions. Unfortunately, when you compile your project, it will then be tied to the version of DLL files you reference. This is why you need multiple projects for each version you intend to target.

A Better Way?

I spent some time researching and investigating whether there was a better way to do this, but didn’t come up with any viable solution. I am aware of the "Specific Reference" option for references. However, according to the documentation, this does not affect the actual compiled library. No matter how I referenced the projects, the final output always needed to reference a specific version of the DLLs.

If you know a better way that will make this entire post obsolete, I would certainly be GRATEFUL if you let me know!

Downloading Sitefinity DLLs

Obviously the first thing you’ll need to get started is a copy of all the Sitefinity DLL files for each of the projects you wish to reference. These are available in your Sitefinity Client account. Go into your downloads and you should immediately see the latest version (SP4) as of this writing.


There is also a link at the top that will take you to the previous versions so you can go as far back as you need to:


While you can certainly download the full project or installer for each version, it luckily turns out that the Patches contain all the updated libraries you will likely need for your project. After extracting all the downloads, each version will contain the needed DLL files in the bin folder.

Sitefinity-Patches Sitefinity-Patch-Contents

Creating the Projects

Now that you’ve got all the references you need for your projects, you need to create the projects themselves. I recommend using the Solution Folders available for Visual Studio Projects to better organize your solution.


The solution folder allows you to create virtual folders to organize your projects by type so that you can keep better track of which projects go with which platform. Here’s how I organized mine:


Now select the appropriate folder and add a new project to it:


In the dialog that follows, setup your project to match the platform (in this case ASP.NET 4.0). Be sure to name it in a way that identifies your project. Previously I used the full version number (i.e. 3.7.1990.2) but this ended up being more confusing that I thought and ended up labeling it with the version and Service Pack number.

Simply repeat this process for the different versions and platforms you wish to support, adding new projects into the appropriate Solution Folder.

Create-New-Project Create-New-Project-2.0

When you’re done you’ll have a mighty solution with all the projects needed to support the different versions of Sitefinity. Here’s what mine ended up looking like.


Assembly Properties

Be sure to make sure all of the Assembly properties match your projects. Although they target different platforms, the project itself is usually a single product, so take some time to sync everything up:

Application-Properties Assembly-Information

Link Source Files

Now you may be thinking that managing 22 copies of source code is a nightmare and you would be absolutely right. Fortunately, Visual Studio has an excellent feature that allows you to "link" to existing source code files so that there is only ONE copy of the source file. This link can be shared to any number of projects, including our 22 Sitefinity projects!

This is exactly what I have done for the Sitefinity Toolkit. In fact, ALL of the project source files are housed within the original project. The other projects simply link to the source files using the "Add Existing Item" menu item, selecting the source code files, and selecting "Add as Link".


Keep in mind that some source files should not be linked, especially if they are for classes that target a specific version of Sitefinity. For example, I implemented workflow notifications for the Generic Content Modules. However, the Community Edition of Sitefinity does not support workflow. So this section of source code files are not linked into the Community Edition projects.

Develop, Build, Deploy!

At this point you are ready to begin developing your project. Be sure you add the references you downloaded for each platform above, and of course make sure you add the correct references to the correct project. It took me a few tries to get it right. However I now have all my solutions setup and they all compiled successfully, allowing me to publish the latest update to the Sitefinity Toolkit.

If by chance a new SP is released, it’s simply a matter of repeating this process for the new project. Just be sure to add it for both versions (Community and Standard) as well as the multiple versions of ASP.NET (assuming you want to support them all).

Of course, depending on your project, it might not be this simple. Some of your support libraries may not be available for other versions of This was the case with JSON, which doesn’t yet have an official 4.0 version. However, I was able to compile the project targeting the 4.0 platform, so it wasn’t much of a setback. Your results may vary.

A Better Way!

One thing I am happy to report is that it appears this article will definitely be obsolete when Sitefinity 4.0 rolls out. Thanks to the new Facade Pattern and Fluent API, which is now version-agnostic, addons and extensions to Sitefinity no longer need to be tied to a specific version!

Want to know more about the new features coming in 4.0? Be sure to register for the Sitefinity 4.0 RC Webinar taking place November 11!

Wrap Up

Although the process to set up the full solution was slightly involved, in the end it wasn’t all that much work. And the benefits of being able to fully support all versions of the latest Sitefinity 3.7 are certainly worth the effort. I hope you’ll agree!

I’d love to hear your feedback, especially from other Marketplace developers. How are you handling targeting multiple platforms, or are you even attempting to do so? If you attempt to repeat this project, please share your results!

Sitefinity Toolkit 1.2 Released, Supports All Versions of 3.7

At long last, I’ve finally been able to successfully compile the Sitefinity Toolkit for ALL versions of the latest Sitefinity version 3.7! A lot of improvements have been added over the years, including fixing a few nasty bugs and completely rebuilding the Caching and Notification features. For a complete changelog and downloads for all versions, check the Sitefinity Toolkit Page.

Full Sitefinity 3.7 Support

As I just mentioned the BIGGEST change in this release is that it is now fully supported for ALL versions of Sitefinity 3.7, including all service packs up to SP4. In addition, all ASP.NET versions are also supported: 2.0, 3.5 and the new 4.0 (which is only currently available for SP4).

As I mentioned in my previous Sitefinity Toolkit update, this presented an interesting challenge, ultimately ending up required a total of 22 Visual Studio projects in the solution. I hope to put together a walkthrough of my experience to help anyone who might have an existing control in the Sitefinity Marketplace and wants to support multiple versions.

Although Sitefinity 4 is coming up fast (be sure and check out next week’s webinar on the RC release!), current developers of 3.7 controls and tools will certainly want to make sure their products are available to anyone who might still be using them. So stay tuned for that very soon!

Mobile Toolkit Conflict

There is an important issue that I was unfortunately unable to resolve is a conflict between the Mobile Foundation (formerly Mobile Toolkit) developed by 51 Degrees and the Sitefinity Administration Login.

You are still able to enable the mobile device detection module, however you must disable the Mobile Foundation in web.config. For instructions, take a look at the updated Mobile Detection post. Disabling the Mobile Foundation will force the detection to fall back to the standard ASP.NET method IsMobileDevice, bypassing the WURFL definitions.

I hope that this change is only temporary while I work with 51 Degrees to try and figure out why this is happening. An update will be posted as soon as I have a fix!

An Important Reminder

Remember always that this Sitefinity Toolkit is a personal project, and is in no way an official Telerik product, nor is it supported officially by anyone other than myself. The software is provided as-is, and should be used at your own risk.

That being said I have tested it successfully on several sites, including this website you’re reading now, but I don’t have the resources to test on every platform and version. Please be sure to TEST, TEST, TEST before deploying this in a production environment. Should you encounter any issues, I would really appreciate your feedback!

With that being said I am pleased to also remind you that the Sitefinity Toolkit is finally permanently free of charge to use as you please. I will still not yet be distributing source code, but the Toolkit itself will always be without cost. Donations are always appreciated, but if nothing else, please send me your feedback so that I can continue to improve it for everyone (including myself)!