Windows 10 Development: Adding Design-Time Data with Blend

In our last post, we installed the MVVM Light Toolkit and defined the basic framework for a simple two-page app with the MVVM pattern. With the ViewModels we created, we now have the containers for the data, but it would be even more helpful to pre-populate them with some sample data to aid in the designing of the app.

Read more at the Falafel Software Blogs: Windows 10 Development: Adding Design-Time Data with Blend

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!