.NET

Bug fix: WPF4 project template for #MVVMLight V3

Laurent Bugnion — Tue, 24 Jan 2012 23:40:09 GMT

Ironically, my last release of MVVM Light V3 was about fixing bugs in templates and making them better. In the process however, seems that I introduced a regression bug in the WPF4 project templates. Yep shit happens.

How do I know if I have the bug?

Check the Programs and Features control panel, and look for MVVM Light. If the “Version” column shows 3.0.2.19, you have the bug. If it shows anything higher, you don’t. For instance, the new version with the bug correction is 3.0.3.19. Also, any version 4.*.*.* does not have this bug.

Alternatively, simply try to create a new WPF4 MVVM Light application in Studio. If you see the following warning, you have the bug.

Upgrading

To fix the bug, simply download V3.0.3.19 from Codeplex and install. You don’t need to uninstall the previous version.

What’s next?

I am working hard on V4 and have some nice improvements coming up. Many people have asked me when the “beta” will come out of MVVM Light, and the answer is “soon”. In the coming few days, I will publish a temporary release that corrects a few memory leaks, notably in the Messenger and in the RelayCommand. This will give expert users time to test and report issues. Then I still have a couple of fixes and I will release a release candidate. I won’t add any new feature after the RC, but will merely fix bugs if people find some. Once the RC is deemed stable, I will release V4 and take a deep breath!

And yes, there will be a V5

Happy coding,
Laurent

Laurent Bugnion (GalaSoft)
Subscribe | Twitter | Facebook | Flickr | LinkedIn

New MVVM Light templates with bug fixes

Laurent Bugnion — Mon, 02 Jan 2012 20:13:28 GMT

The current version of MVVM Light had a couple of issues in the project templates. The most annoying one was causing a problem when creating new projects: The GUIDs used to uniquely identify the project were in fact not re-generated properly every time, and we ended up with the same GUID in every new project. The symptoms are the following: If you side-load an MVVM Light application, and then side-load another one, you will see that the first one is overwritten. Note however that this is only an issue when side-loading applications: The GUIDs are properly re-generated and overwritten by Microsoft during the app approval process.

This was not really an issue with WPF and Silverlight applications (which is why the bug was never found until now), however the Windows Phone uses these GUIDs to check if the application is already installed on the Windows Phone device or not.

I also took this occasion to update the templates with some information in the AssemblyInfo.cs, so that should make it even easier to fill the assembly information.

I just published a new MSI that corrects the issue. You can install the new MSI on top of the existing one. As usual, there is an MSI for MVVM Light V3 and one for MVVM Light V4 beta.

Fixing the issue in existing applications

If you encounter this issue in existing application, you can use the following steps to correct it. Note that I recommend you to follow these steps for every MVVM Light application.

Start the GUID generator installed with Visual Studio (open the Start menu and type GUID to find it).
In the GUID generator, select the Registry Format.
Press the New GUID button and then the Copy button.

Open the CSPROJ file in Notepad (or any text editor).
Locate the <ProjectGuid> attribute.
Select its content and paste the GUID you previously copied.

For Windows Phone projects only, in addition:

In the GUID generator, press the New GUID button and then the Copy button.
Open the file WMAppManifest.xml (in the Properties folder).
Find the ProductID attribute and replace its content with the GUID you previously copied.

Projects exposed to COM

Some project also have a GUID in the AssemblyInfo.cs. Open this file in Visual Studio or in Notepad and check if you can see a GUID there. If there is one, copy a new GUID from the GUID generator and replace the old one with the one you just copied. Be careful to remove the opening ‘{‘ and closing ‘}’.

That’s it

Apologies for this bug, and thanks to everyone who reported it and helped make MVVM Light better.

Cheers,
Laurent

Laurent Bugnion (GalaSoft)
Subscribe | Twitter | Facebook | Flickr | LinkedIn

MVVM Light installers and Nuget (including Silverlight 5) #mvvmlight

Laurent Bugnion — Sun, 18 Dec 2011 21:10:12 GMT

I just pushed two big updates to MVVM Light setup components.

MSI installers with Silverlight 5 support

The MSI installers are available on Codeplex. The current version supports Silverlight 3, Silverlight 4, Silverlight 5 (new), WPF 3.5 SP1, WPF 4, Windows Phone 7.0 and Windows Phone 7.1. The installer for V3 is available, as well as the one for V4 beta.

NuGet support including Silverlight 5

I also pushed a new version of the NuGet packages which includes Silverlight 5. To install MVVM Light into an existing application with the help of the NuGet package manager in Visual Studio, check the instructions.

If you look for “mvvmlight” on NuGet, you will find four packages:

MVVM Light: The whole package, libraries + ViewModelLocator + MainViewModel. Installing this also modifies App.xaml to install the ViewModelLocator. This package is for V3 of MVVM Light!
MVVM Light libraries only: Installs only the DLLs and references them. This package is for V3 of MVVM Light!
MVVM Light [Preview]: This is the whole package too, but for V4 beta.
MVVM Light libraries only [Preview]: Just the DLLs, for V4 beta.

Update on V4’s availability

One of the most annoying issues in V3 is a memory leak that can appear in the Messenger component in certain circumstances. I will post details in due time, but there is indeed a risk that an instance is not garbage collected if it is registered with the Messenger with a non-static method, and if the developer omits to unregister the instance before deleting it.

Because of the promise of a “weak” registration, I really want to solve this issue. Currently, I am able to completely solve it in WPF, and to solve it in most cases in Silverlight (including Windows Phone). There is still one special case in Silverlight where a memory leak may remain, and I am currently working on handling this. I am not sure that there is a solution for this last scenario, but there are other alternatives that it is not a blocking issue anymore.

Once this fix is fully tested, I still have a few things I would like to add in V4. However I am also aware that we have been in beta (and alpha) for quite some time already, and it is very possible that I procrastinate some of these features into V5.

Happy coding!
Laurent

Laurent Bugnion (GalaSoft)
Subscribe | Twitter | Facebook | Flickr | LinkedIn

MVVM Light template and WCF services (or any ASP.NET application for that matter)

Laurent Bugnion — Wed, 07 Dec 2011 21:36:33 GMT

I was recently made aware of a couple of people having issues with WCF services (or ASP.NET applications) when using the MVVM Light project template for Silverlight. There is a blog post and a StackOverflow question, so what exactly is happening there?

Well in fact it is pretty simple when you know how Silverlight connects to web services. Due to the security model of Silverlight, the application cannot connect to a web site if it is not originating of this very website. In laymen’s terms, it means that the application can only connect to a web server if it also comes from the same webserver. For example, if the Silverlight application is served by http://www.galasoft.com, it won’t be able to connect to, say, http://www.cnn.com without getting an exception. We talk about cross-domain access restrictions.

Of course there are ways around that, for instance a website can specifically give access to Silverlight applications through a configuration file.

In the case that concerns us, it is exactly what is happening. You see, the MVVM Light Silverlight project template creates a Silverlight application without an ASP.NET host. I didn’t add one because I didn’t want to complicate the template too much. And also, to be honest, because adding a web project is super easy, but of course only if you know how to do, and this is exactly what we will do here!

Creating the application

The steps to create the application and the WCF service are as follows:

Create the MVVM Light application using the MVVM Light project template for Silverlight.
Right click on the solution in the Solution Explorer and select "Add, New Project from the context menu.
From the WCF category, select a WCF Service Application and create it.
Build the application.
Right click on the MVVM Light project and select Add Service Reference from the context menu.
In the Add Service Reference dialog, click on Discover.
Make sure that the found service is the one you want to connect to, and click on OK.
In the MVVM Light application, open the file Model/DataService.cs and modify the code as follows:

public class DataService : IDataService
{
    public void GetData(Action<DataItem, Exception> callback)
    {
        var client = new ServiceReference1.Service1Client();
        client.GetDataCompleted += ClientGetDataCompleted;

        client.GetDataAsync(1234, callback);
    }

    void ClientGetDataCompleted(
        object sender, 
        ServiceReference1.GetDataCompletedEventArgs e)
    {
        var callback = e.UserState as Action<DataItem, Exception>;

        if (callback == null)
        {
            return;
        }

        if (e.Error != null)
        {
            callback(null, e.Error);
        }

        callback(new DataItem(e.Result), null);
    }
}

This code uses an asynchronous service call pattern where the callback (a reference to a method passed as Action by the caller) is saved in the service call. Then when the asychronous call returns (in the Completed event), the callback is retrieved from the UserState. If an error occurred, the callback can be used to pass this error to the caller. Otherwise, a new DataItem class is created and passed to the called.

Details about this pattern can be found in my talks Understanding the MVVM pattern and Deep Dive MVVM.

So why doesn’t it work?

If you run the application now (making sure that the MVVM Light project is selected as Startup Project), you will first see a warning dialog and then an exception. What happened?

What happened here is exactly the cross-domain issue I mentioned: The Silverlight application is not explicitly hosted into a web application, so Visual Studio is using an auto-generated HTML page instead, and running it from the embedded web server (“Cassini”). In fact, unless you explicitly specified otherwise, the test page is run in “file mode” instead of HTTP mode. The URI in the web browser window starts with C:\ for instance, instead of http://.

In those conditions, the access to the WCF service is (justly) denied, and you get a security exception.

Correcting the error

In order to correct the error, you can either add a cross-domain policy file to your WCF application, or host the Silverlight application in the same web project as the WCF service. Let’s do that now:

Right click on the WCF Service application in the Solution Explorer, and select Properties from the context menu.
On the left, select the Silverlight Applications tab.
Click on Add.
Select Use an existing Silverlight project in the solution and make sure that your MVVM Light application is selected in the combo box.
Make sure that Add a test page that references the control is checked, as well as Enable Silverlight debugging.
Press Add.

This creates two new files in your WCF Service application: One is suffixed TestPage.html and the other is suffixed TestPage.aspx. We typically don’t need the ASPX one so you can safely delete it.

Right click on the WCF Service application and select Set as StartUp Project from the context menu.
Right click about the HTML test page and select Set as Start Page from the context menu.

By doing this, we force Visual Studio to serve the HTML page and the Silverlight application from the same URL as the WCF Service, and to serve it as HTTP. This is possible because a WCF Service application is nothing else than an ASP.NET web server running WCF. So the same web server can deliver HTML, Silverlight and of course WCF.

If you run the application now, you will see the following result:

Note that the warning shown earlier will still appear, but it is really just a warning, and you can safely turn it off. Just remember the cross-domain restriction when you publish your Silverlight application to another web server!

Success, we hit the WCF service and returned with a valid result! In fact, you can verify by placing breakpoints in the DataService.GetData method on the client, and in the Service1.GetData method on the server. Then press F5 to run the application in Debug mode and notice how you can easily debug both the client and the server at the same time.

What about the opposite way?

It is also possible to add a new MVVM Light application to an existing WCF Service application with the following steps (I am going a bit faster now, I am sure you will get it easily):

Open the existing WCF Service application.
Right click on the Solution and select Add New Project.
Select the MVVM Light project template for Silverlight and add a new project.
Build the application.
Just like before, add a Service Reference to the Silverlight application.
Again, just like before, add the Silverlight application to the WCF Service application (WCF Project Properties, Silverlight Applications, Add…).

Summary

Hopefully the confusion around this is cleared now. In summary:

Silverlight applications are restricted to access cross-domain web servers (unless explicitly authorized to do so).
The default MVVM Light application does not have an explicit host, so it runs off the default test page.
You can however easily add the MVVM Light application to the WCF Service application and then run it and debug it.

Note that the steps above can be used to add an MVVM Light application (or any Silverlight application) to any ASP.NET application, be it WCF Service application, ASP.NET MVC application or “classic” ASP.NET application.

Happy coding!
Laurent

Laurent Bugnion (GalaSoft)
Subscribe | Twitter | Facebook | Flickr | LinkedIn

MVVM Light Toolkit for Windows 8 (preview) #mvvmlight #win8

Laurent Bugnion — Mon, 03 Oct 2011 19:28:19 GMT

I was very optimistic when I first saw Metro style apps coded in C# on Windows 8, because for the most part they are not much different than the well known XAML/C# pair on Silverlight or WPF. This led me to brag a bit about probably having a port of MVVM Light ready “in a few days”. Of course I didn’t take in account that I would have a great time the week after //build in Seattle, with fantastic weather and tons of friends to have dinner and conversations with. Needless to say, the few days turned out, in fact, to be a couple of weeks.

Nonetheless, I am proud and happy to announce the availability of MVVM Light Toolkit for Windows 8. Let’s be clear, this is a preview version. All the unit tests are green for the selected components (there are a couple of components not ported yet, see the section below titled “Missing components”). However, a green unit test does not quite mean that the tested component is completely safe to use, so please be careful with that material and send me your feedback if you find issues.

Installation

MVVM Light for Windows 8 is a side-by-side install with the standard MVVM Light V3 or V4 beta. Simply download and run the MSI from Codeplex. As usual, the last step of the installation performs a “/setup” of Visual Studio to actualize the project template cache, and unfortunately this last step can last very long. Please be patient and don’t cancel before the end! The installation process is very similar to that described on the MVVM Light installation page (except that there is no NuGet installer for VS11 yet).

Note however that if you uninstall MVVM Light V3/V4b, but still want to keep MVVM Light for Win8, you may have to repair MVVM Light for Win8. Simply run the installer again and select “Repair”.

Ported components

Almost all MVVM Light components are also available in the Windows 8 version. The ported components are:

ObservableObject including all ways to raise PropertyChanged.
ViewModelBase including all ways to raise PropertyChanged.
Messenger including all message types except DialogMessage (see below).
RelayCommand with and without parameter.
SimpleIoc which might well be the very first IOC container working on Windows 8.

File, New Project

I also created a Metro style version of the MVVM Light project template. To create a new MVVM Light-powered Metro Style application, follow the steps:

Select the menu File, New, Project.
In the New Project dialog, select the category Visual C# / Wndows Metro style and double click the MvvmLight (Win8) template.

The created application is a very simple MVVM application, very similar to the ones that get created in Silverlight, WPF or Windows Phone 7: it contains a model with IDataService, a dummy runtime implementation and a design time implementation. The ViewModelLocator is available and “wired” (using the SimpleIoc container) as well as a MainViewModel that is set as DataContext on the MainPage.

Missing components

Skins: There is a small change in the way that resource dictionaries are handled in Windows 8. I need to sort things out, so right now there is no “MainSkin.xaml” in the project template.
DialogMessage: This type is bugging me in V3/V4b because it is bringing the MessageBoxResult type into the ViewModel. I am looking at ways to make it better by converting the MessageBoxResult into a vanilla Boolean. In Windows 8, MessageBoxResult does not exist anymore (there is no MessageBox or popups of any kinds in Metro style apps). Consequently, the DialogMessage does not build, and I decided to just remove it for now. I will add it again when I refactor to the “vanilla” version.
EventToCommand: There are no Blend behaviors in Windows 8 yet (important word: yet). I am looking at ways to have behaviors on Windows 8 before Blend 5 for XAML gets released. Stay tuned.
DispatcherHelper: The Dispatcher object has changed quite a lot in Windows 8, and I am looking at ways to keep the DispatcherHelper compatible with previous versions of MVVM Light by wrapping these differences. It shouldn’t be a big deal, but I want to give myself a little time to get it right (hopefully).

Next steps

I intend to build a small sample application (very similar to the one I built for my MIX11 talk) to try the various components in real life conditions. This will of course be the topic of an upcoming blog post.

I encourage everyone to try these components in Windows 8 preview, and please don’t be shy with your feedback!

Cheers,
Laurent

Laurent Bugnion (GalaSoft)
Subscribe | Twitter | Facebook | Flickr | LinkedIn

Breaking change: Raising PropertyChanged with string.Empty in WinRT / Windows 8

Laurent Bugnion — Sun, 25 Sep 2011 21:57:41 GMT

In the developer preview of Windows 8, I just noticed a breaking change in the way that data bindings react to the PropertyChanged event.

First a bit of background: Often, objects that are databound to the UI are simple data objects (also called ViewModels) that implement the INotifyPropertyChanged interface. This interface is very simple and defines just one event, the PropertyChanged event, that needs to be raised by the ViewModel when one of its property changes. It is what makes the ViewModel “observable”. If a property of another object (typically a UI element) is data bound (through a Binding object, often set declaratively in XAML), then the value of the observing property will be synchronized to the value of the observable property.

Raising the PropertyChanged event requires an instance of the PropertyChangedEventArgs class, which takes a string as sole parameter of its constructor. The string to be passed is the name of the observable property.

Raising with string.Empty or null

In WPF and Silverlight, it is possible to raise the PropertyChanged event with an instance of the PropertyChangedEventArgs class constructed with string.Empty (or null) instead of an existing property’s name. When a PropertyChanged event is raised in this manner, the UI will re-query the value of each property of the ViewModel that is data bound to the UI. This is a convenient way to raise but one event and force the UI to update itself in response to cascading changes, for example. As such, this can be a good way to increase the performance of the application.

The breaking change in WinRT

However, while unit testing the version of MVVM Light for WinRT, I found out that raising the PropertyChanged event with an empty string or null does not update the bindings. I quickly coded a repro, and then coded the exact same code in Silverlight, and indeed the two applications do not react the same at all.

Hopefully this is only an oversight and this will be fixed in a future version.

Cheers,
Laurent

Laurent Bugnion (GalaSoft)
Subscribe | Twitter | Facebook | Flickr | LinkedIn

Quick tip: Select the correct INotifyPropertyChanged in Windows 8 / WinRT

Laurent Bugnion — Sun, 25 Sep 2011 20:47:24 GMT

Microsoft loves MVVM and INotifyPropertyChanged so much that they included this very useful interface twice in the new WinRT framework. Unfortunately, only one of these is working correctly (and the other one is likely a bug, remnant from the past )

When implementing INotifyPropertyChanged, make sure that you select the correct one! The one you want to use is into Windows.UI.Xaml.Data. The old one, the one you DON’T WANT is into System.ComponentModel (the same namespace it was in WPF and Silverlight). If you select the wrong one, the Bindings will not be updated and the UI will remain dead as a dead fish.

I mentioned before that Microsoft took the “once in a lifetime” opportunity (well, 5-10 years is a lifetime in the world of computers) to clean up and rearrange classes within the framework. This is one of the signs right here. As for the System.ComponentModel.INotifyPropertyChanged, I guess it will be removed in a later release of the WinRT framework.

Update: Indeed I was just told by the excellent and always vigilant Tim Heuer that this bug has already been fixed. I guess we will see the fix in the next release to developers of Windows 8.

Cheers,

Laurent

Laurent Bugnion (GalaSoft)
Subscribe | Twitter | Facebook | Flickr | LinkedIn

Detecting design mode in Windows 8/WinRT

Laurent Bugnion — Sun, 25 Sep 2011 19:02:59 GMT

One of the very useful features of the MVVM Light toolkit is to help with the creation of design time data, in order to give something to see on the design surface (Expression Blend, Visual Studio designer). This is especially useful when designing list controls such as ListBox, ComboBox, etc. Without design time data, these controls will remain empty, and the designer will not see what he is working on. This can cost a lot of time and cause frustration.

Detecting design mode was always incompatible in WPF and in Silverlight.

In WPF, we use a rather complicated snippet:

var prop = DesignerProperties.IsInDesignModeProperty;
_isInDesignMode
    = (bool)DependencyPropertyDescriptor
                 .FromProperty(prop, typeof(FrameworkElement))
                 .Metadata.DefaultValue;

In Silverlight, there is a convenient property:

_isInDesignMode = DesignerProperties.IsInDesignTool;

In WinRT, we have to use yet another property:

_isInDesignMode 
    = Windows.ApplicationModel.DesignMode.DesignModeEnabled;

Abstracting the differences

These differences can make it difficult to share code between these environments. This is why the MVVM Light toolkit abstracts these and provides a convenient property on the ViewModelBase class:

(within a ViewModel deriving from ViewModelBase):

if (IsInDesignMode)
{
    // Create design time data
}
else
{
    // Create run time data
}

(within any class not deriving from ViewModelBase):

if (ViewModelBase.IsInDesignModeStatic)
{
    // Create design time data
}
else
{
    // Create run time data
}

Happy coding!

Laurent

Laurent Bugnion (GalaSoft)
Subscribe | Twitter | Facebook | Flickr | LinkedIn

Dealing with types in WinRT

Laurent Bugnion — Sun, 25 Sep 2011 18:35:54 GMT

Another quick tip: Most of the interaction with the System.Type class in Windows 8 is now done through the TypeInfo class. An instance of TypeInfo for a give type is retrieved using an extension method called GetTypeInfo(). Note that since this is an extension method, it will not be visible in Intellisense unless you add a reference to System.Reflection in the “using” section:

// Needed for the extension method
using System.Reflection;

(...)

var info = myType.GetTypeInfo();

// Was: string name = myType.Name
string name = info.Name;

// Was: Type[] interfaces = myType.GetInterfaces();
IEnumerable<Type> interfaces = info.ImplementedInterfaces;

// Was: bool check = myType.IsSubclassOf(anotherType);
bool check = anotherType.GetTypeInfo().IsAssignableFrom(info);

(etc...)

Note: IsSubclassOf and IsAssignableFrom do not have the exact same meaning, however in many cases it should be able to use IsAssignableFrom. Make sure to check the documentation to verify that this is indeed what you want!

Hopefully this is useful to WinRT coders out there!

Laurent

Laurent Bugnion (GalaSoft)
Subscribe | Twitter | Facebook | Flickr | LinkedIn

Running unit tests in Visual Studio 2011 and Windows 8 (WinRT)

Laurent Bugnion — Fri, 23 Sep 2011 22:50:42 GMT

This is a quick tip, because it confused me at first. But thanks to the always excellent Tim Heuer and Peter Provost (from the Visual Studio team), here is the answer:

Usual disclaimer: This is for XAML/C#. I am not sure how this works for the other programming stacks.

Creating unit tests for your WinRT application/library

Start Visual Studio 2011.
Create a new project.
From the Add New Project dialog, select Unit Test Library (In the Visual C#/Windows Metro Style category). Give a name to the project and press OK.
Either open the unit test class that was created, or create a new class. No need to select a fancy template, just create a new empty class.
Decorate the class with a [TestClass] attribute.
Create a public method with no parameters, and decorate it with a [TestMethod] attribute.
Right click on the unit test project and select Add Reference from the context menu.
In the Reference Manager, select Solution and then the project you want to write tests for. Then press Add and then Close.

You can now write your tests, using the usual Assert syntax. Here is a simple example.

[TestClass]
public class UnitTest1
{
    [TestMethod]        
    public void TestAlwaysPass()
    {
        const string expected = "Any text";
        var myClass = new ClassLibrary1.Class1(expected);

        Assert.AreEqual(expected, myClass.Parameter);
    }

    [TestMethod]
    public void TestAlwaysFail()
    {
        const string expected = "Any text";
        var myClass = new ClassLibrary1.Class1(expected);

        const string notExpected = "Another text";
        Assert.AreEqual(notExpected, myClass.Parameter);
    }
}

Running the unit tests

To run the unit tests you just wrote, follow the steps:

Select the menu View / Other Windows / Unit Test Explorer.

Build your application. You should now see the unit tests you wrote in the explorer window.

Press Run All to run all the unit tests.

Hopefully this quick tip will be helpful!

Cheers

Laurent

Laurent Bugnion (GalaSoft)
Subscribe | Twitter | Facebook | Flickr | LinkedIn