Update: The VSIX installer for version 5.5.0.1 of Simple MVVM Toolkit includes the toolkit code snippets! They are included as a pkgdef (VS add-in). So after installing the toolkit, press Ctrl+K, Ctrl+X and select a C# or XAML snippet from the Mvvm folder (or just type the C# code snippet name).  Note that if you are using ReSharper, you will need to select RESHARPER, Options, Environment, Intellisense, General, and select Visual Studio.

Simple MVVM Toolkit v5.0 for Visual Studio 2013 is now published! There is support for WPF 4-4.51, Silverlight 5, Windows Store 8.1 and Windows Phone 8. Come and get it! https://simplemvvmtoolkit.codeplex.com/

Adding support for Windows Store 8.1 and Windows Phone 8 was not that difficult. This was due primarily to the work that had been done in v4 of the toolkit, namely, placing as much functionality as possible in the SimpleMvvmToolkit-Common assembly, which is a portable class library.  For the common library I set target framework compatibility to .NET Framework 4.5 and higher, Silverlight 5, Windows Phone 8, and Windows Store (Windows 8) and higher.

One thing, however, that differs among these frameworks is how to marshal code that is running on a background thread back onto the main UI thread.  For standard code-behind, this made much easier by the async / await pattern, which handles the marshaling automatically. However, it is not as easy when setting a view-model property from a background thread.  You would have to get onto the UI thread by placing the code to set the property after the await statement.  That’s not really too much to ask, but wouldn’t it be easier if you didn’t have to think about it? Shouldn’t the framework would handle the marshaling for you?

That is precisely what Simple MVVM Toolkit does. But to make the magic happen, some things need to take place under the covers, and there are some differences between Silverlight and other frameworks, such as WPF, Windows Store and Windows Phone 8.  The latter require that you initialize the dispatcher while on the main UI thread. To allow this, UIDispatcher has an Initialize method, which you should call at app startup.

#if !SILVERLIGHT
    /// <summary>
    /// Invoke from main UI thread.
    /// </summary>
    public static void Initialize()
    {
        #if NETFX_CORE
        WindowsDispatcher windowsDispatcher = CoreWindow.GetForCurrentThread().Dispatcher;
        #else
        WindowsDispatcher windowsDispatcher = WindowsDispatcher.CurrentDispatcher;
        #endif
        _dispatcher = new UIDispatcher(windowsDispatcher);
    }
#endif

One goal of mine was to add support for Windows Store and Windows Phone 8, but another pressing concern was to address the difficulties some users experienced trying to install v3 and v4 of the toolkit.  The download to those versions is an MSI installer created using InstallShield.  Unfortunately, Microsoft removed the built-in installation templates from Visual Studio, and the “express” edition of InstallShield pulled in dependencies from the machine on which the installer was created. The end result was that .NET Framework assemblies were removed by the installer when the user uninstalled the toolkit – yikes! There were also issues with the placement of the project templates in the user’s personal folder.

To address these issues and create a smother installation experience, I decided to deploy v5 of the toolkit as a VSIX – Visual Studio Extension. (I also intend to re-deploy v3 and v4 of the toolkit as VSIX’s.) This solves the main problem of unintended dependencies, as well as the placement of project templates.  It also removes the need to install the template wizard in the Global Assembly Cache, because it can be included with the VSIX installer.

This prompted me to re-think another aspect of the installer, which was creating registry entries so that the toolkit assemblies would show up in the Add References dialog.  To solve that, I turned to NuGet. It’s possible to include NuGet packages in a VSIX file and configure the project templates to pull them in. I also was able to consolidate all versions of the toolkit into a single NuGet package: SimpleMvvmToolkit.  That’s because a single package can contain multiple assemblies, each targeting a different platform. NuGet knows how to install the right assemblies based on the framework of the project using the package.

There are some trade-offs in the decision to use VSIX and NuGet. The main one is that VSIX does not support the installation of code snippets.  So what I plan to do is instead create a VSI file for the code snippets.  Secondly, it’s not practical to use a VSIX for installing things like samples and source code.  So I simply added them as separate downloads from the CodePlex site.

One last change to the toolkit is with the source code repository on CodePlex.  I had been using TFS for source code control, but the repository only included the class libraries and not other artifacts, such as NuGet packages and installers. I hesitated to redo the directory structure because of how difficult it is to do in TFS.  I also had several developers who wanted to contribute to the project, so switching to a distributed system like Git started to make sense.

It took some time to learn the in’s and out’s of Git, but the effort was well worth it. CodePlex recently added support for Git and has a nice set of instructions. I asked the kind folks at CodePlex to remove the existing TFS repo and replace it with a Git repo. After installing Git for Windows and TortoiseGit, I cloned the repo locally, added the files, committed them, and pushed them up to CodePlex. It was incredibly easy to do.

This makes it more straightforward for anyone wanting to contribute to the project.  All you have to do is fork it, create a local branch, make your changes, then issue a pull request, which I can evaluate and them merge into the main branch.

Enjoy.