Silverlight

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 for Silverlight 5 is on Codeplex #mvvmlight

Laurent Bugnion — Sat, 10 Dec 2011 19:29:43 GMT

Here we go! After the Microsoft team released version 5 of Silverlight yesterday, MVVM Light is available for this version of the framework too. I did not create the installer yet (that will take a few more days), but you can download the source code and build it yourself easily.

With this latest release, this puts the number of supported frameworks to 8: .NET 3.5 SP1, .NET 4, Silverlight 3, Silverlight 4, Silverlight 5, Windows Phone 7.0, Windows Phone 7.1 and Windows 8 (preview).

Dropping Silverlight 3 and WP7.0?

That said, I am considering dropping old frameworks now for new development. So here is a chance to make yourself heard, tell me if you think that it is OK to drop Silverlight 3 and/or Windows Phone 7.0 and to concentrate on the 6 other supported frameworks:

Thanks and happy coding!
Laurent

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

Silverlight 5 is released!

Laurent Bugnion — Fri, 09 Dec 2011 19:59:03 GMT

Microsoft just released the version 5 of Silverlight! It’s a great news and I really want to congratulate the whole team on this impressive collective effort. The official announcement is on the Silverlight team blog!

The purpose of this article is not to be exhaustive about the list of features (there have been, and will be, many more very detailed articles such as this series on the Silverlight blog) but rather to explain why this version in particular makes me happy to be a Silverlight developer (features listed in no particular order!).

3D!

One thing is making me really happy and excited: the 3D integration. It is now possible to include and manipulate 3D models within a Silverlight application. This model is very similar to what XNA offers, which means that existing XNA developers will feel at home very fast with this new platform. It also means that existing 3D models can quite easily be run in Silverlight 3D. I am sure we all have in mind the pretty amazing demo with Scott Gu’s avatar during the Silverlight 5 firestarter (jump to 51:11).

I am really happy to have 3D integration in Silverlight now, because I have been working for the past few weeks on a new application for Kinect for Windows involving a 3D human avatar integrated in a Windows Presentation Foundation. The integration is completely seamless, and it looks like the avatar is completely part of the rest of the application. However, the rest of the application is WPF, with all the XAML, binding and MVVM goodness that it brings. This kind of seamless integration is now also possible in Silverlight, and that opens the door to a lot of pretty cool applications and a new kind of user experience.

In-browser trusted applications

We all know (or heard of) the Out-Of-Browser (OOB) application model which allows Silverlight to run outside of a web browser, just like a Windows application in its own windows, with its own shortcut, etc. There is also an elevated trust model for OOB, declared at build time, which allows such applications to perform tasks that are usually not allowed (such as saving or reading files from certain locations on the computer, run in full-screen with full keyboard support (ideal for kiosk applications!), host HTML pages within the Silverlight application, etc.

These features were already available in Silverlight 4, however in Silverlight 5 they are also possible inside the web browser. This makes the delivery of such applications a little easier, since the user does not have to “install” them and deal with a shorcut.

Trickplay

This feature allows to play video at various speeds, and even includes pitch correction to avoid that the speaker sounds like a chipmunk! This is especially useful when watching conference sessions: watch a whole 60 minute session in 30 minutes, and use the rest of the hour to be with your family instead

Breakpoints in bindings

This one is pretty cool: Who has never had to debug a binding, because the binding expression had a typo, or the value was not what you expected? it was pretty cumbersome before! Well with Silverlight 5, you can set a breakpoint right in the XAML binding expression, and the debugger will break and allow you to inspect the expression!.

Performance, profiling

A lot of work has been put into performance too, and a new set of tools helps to profile the application and identify critical areas that need perf tuning.

Pinvoke

This is like COM on steroid: This allows your Silverlight application to access pretty much any of the Win32 APIs directly from within your app. There are even ways to listen to Win32 messages, for example to be notified when a new USB drive is inserted (this is only an example!). There is a good article on pinvoke by Alexandra Rusina (one of Silverlight’s PMs) here.

Note that pinvoke only works with elevated permissions, which really makes sense (I wouldn’t want any script kiddy to be able to format my hard drives without saying “OK” first)!!.

And more…

There are a lot of other improvements, notably useful when you use the MVVM pattern in Silverlight. For example, the ability to search for an Ancestor in a RelativeSource binding (something we had since the beginning in WPF, and because it was missing here led to some cruel workarounds in some applications in Silverlight…) is a good example of these apparently small changes, but that will mean a lot when you do need them.

With version 5, we have a super mature version of the framework!

What about Mac? What about other browsers? What about delays? What about Maryjo?

As usual it is interesting to witness the drama around the (perceived) delay in the delivery of this massive new version. It is important however to remember that there had not been any official announcement about a delivery date (the only thing we had heard was Scott Guthrie – who is not in charge of this product anymore by the way - talk about “end of November”). With a delivery in the first half of December, and considering that much time has been spent on last minute bugs, making this version as stable as can be, and (again) considering the massive additions to this new version, I say kudos to the team!

Edit: Maryjo felt insulted and I am a nice guy, so let me rework that paragraph a bit. Yeah I went too far and personal, so hopefully this is better.

Maryjo Foley, who seems to be reporting and speculating on a lot of bad news these days, reported that Mac OS would not be supported for Silverlight 5, and even worse that only Internet Explorer would be supported on Windows.

Side note: She actually reported that “One of my contacts said he believed that the final version of Silverlight 5 may only work with Internet Explorer on Windows and won’t work on Mac OS platforms or with other browsers at all. (Silverlight 4 supports Windows and Mac OS X and the IE, Chrome and Safari browsers.)”. Notice the lack of named reference, the “he believed” and the “may work”.

It’s a good example of why we should take this kind of “journalism” with a grain of salt. We are very rational people, fond of science and technology, and yet we seem sometimes to act like schoolgirls when someone writes something on the web. At this point, I think it is good to remember that Maryjo often reports hearsay and rumors. I don’t mean that she is always wrong, not at all, and in fact I do read her column with interest. But I always take it with a (large) grain of salt, and I remember that until a product is released, we don’t know what it will support. Everything else, really, is conjectures. A good thing to remember while Windows 8 is in preparation!

Side note again: It is very painful to insiders to read this kind of articles (if you can call it that) while we knew very well that it was completely wrong. Unfortunately, the non-disclosure agreement that binds us to Microsoft prevents us from correcting assertions like this, and we had to sit down and watch. This is very unfortunate and painful. I really hope that people learn, some day, to be reasonable when it comes to technology (but I am not holding my breath).

To be clear: the list of supported web browsers and operating systems did not change. It is available at http://www.microsoft.com/silverlight/what-is-silverlight/.

Some restrictions

There are a few restrictions around the 3D rendering, for security reasons. The best summary I found so far is on David Catuhe’s blog. Security restrictions are always annoying but the alternative is letting unsafe code run on the user’s computer, and we all know how Microsoft handled that in the past (ActiveX anyone?) so I guess that we need to accept that they err on the side of security this time. (Edit: updated on 12/10/2011).

Also, like previously, COM access does not work on Mac OSX and as I mentioned above, p/invoke is also only available on Windows. Both these features require elevated permissions by the way.

What about MVVM Light?

MVVM Light will of course support Silverlight 5, and I will release a version soon. I just need a little more time running my tests and making sure that everything is working as expected. Stay tuned to this blog for an announcement about the release of MVVM Light for Silverlight 5!

A few additional updates

Well there was a nice storm on Twitter, and within the noise I managed to grab a few useful facts.

First, the Blend preview for Silverlight 5 is available here. I did not verify that it works with Silverlight 5 RTM, but I think it should.

Then, Silverlight 5 will be supported until December 2021. That’s 10 years of support.

The offline documentation can also be downloaded.

Finally there was a lot of passionate discussions on Twitter tonight. I think it was especially interesting to confront the view of tech journalists versus MVPs vs developers. Bottom line is that there is a lot of passion around tech these days. I personally think it is too much passion, but some disagree and I think we will have to live with that for years to come…

Cheers,
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

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

My thoughts about Build, Windows 8, WinRT, XAML and Silverlight

Laurent Bugnion — Sat, 17 Sep 2011 19:32:12 GMT

Last week, Microsoft held their long awaited Build Windows (or simply "Build") conference in Anaheim CA. About 5000 people packed the convention center to discover the latest version of the Windows operation system: Windows 8.

This is a very major iteration (much more than the Windows Vista –> Windows 7 transition) (and also, it is an early preview so it is quite unfinished ;) As such, we will definitely need a bit more time to play with it before we can express a truly informed opinion. Of course that didn't stop tech journalists and dumbasses all over the world to (again) express complex thoughts such as "Microsoft is abandoning Flash/Silverlight in Windows 8" or to ride again the "Silverlight is dead" roller coaster.

Side note: Did I just call you a dumbass? Well if you are on this blog, reading, the answer is most probably NO. I want to be very clear: This comment was not targeted at Scott Barnes either (though, why would he think it was? mmm food for thoughts there) ;) The dumbasses are the haters, the people who keep taking any occasion to spread FUD because they do not know it, understand it, or simply because it has the name Microsoft on it. So no, I did not call YOU a dumbass. Apologies for not making that super clear from the start. After all, you read my blog, that makes you my best friend (or something ;)

Of course, as usual (it is starting to get annoying, right?), these opinions are far from the truth and attempt to put a negative spin on everything Microsoft does. I won't even speculate why that is, but based on track records, it is safe to say that this kind of prediction is not very accurate or rational (remember when we were told that we would not be able to use anything else than HTML to build Windows 8 apps? Yeah those were the days ;)

So what is the reality now? Here is what we know:

(disclaimer: this is based on what I understand after many discussions with experts. However, I am not a Windows 8 expert, I just played with it for 5 days now. If anything here is incorrect, it is my own fault and not the experts')

Desktop vs Metro style

Windows 8 has two modes, one named "Desktop" and one named "Metro style". These names are temporary and may very well change before release. The "Metro style" applications are also referred to as "immersive apps".
Silverlight and WPF will continue to run as is on Windows 8 in Desktop mode. You can think of the Desktop mode as Windows 7++, an improved version especially optimized for touch operation. Honestly using the Desktop mode with the fingers is an amazing pleasure now, while it was a pain in Windows 7.
All applications (as far as I tested) that run in Windows 7 also run on Windows 8 Desktop mode. I installed Silverlight and Flash already on mine, OneNote, Live Writer, Live Messenger, Skype and more. No issues at all so far (apart from an occasional instability because "it's an early preview" (TM)).
Metro style applications (aka "immersive apps") are a new class of apps altogether. They are in fact much more similar to a Windows Phone 7 app than to a classic Windows application. They are optimized for Touch and can also be actuated with keyboard and mouse, though the experience is better with the fingers.
Metro style apps are sandboxed for security. Again, this is very similar to the Windows Phone 7 model.
Metro style apps can be developed with 3 possible stacks: XAML/C++, XAML/C# or HTML/CSS/JavaScript. They rely on a set of API named "WinRT" which is exposed in a very consistent manner for the three stacks.

This last point is important. It means that there is no reason to choose one or the other stack based on WinRT features that you want to address. Because of the chosen architecture, the features will automatically be available to the three stacks. In some cases however, some features will be hidden on purpose from one stack or the other, because they might simply not make sense.

The Windows 8 programming model: The blue side is largely unchanged (.NET 4.5, Silverlight 5, Win 32) and everything runs as usual. The green side is new (see the next section).

Programming stacks for WinRT

Amongst the three stacks, there will be some differences due to the languages. For instance, JavaScript and C# don't address asynchronous programming in a similar manner (by the way Windows 8 is sporting C# 5, so you have the great "await" and "async" keywords that are making asynchronous programming much more similar to synchronous coding). Similarly, JavaScript is more dynamic than C#, but C# is easier to code and to debug, etc.
All three stacks talk to unmanaged code (the WinRT libraries). For C++, this is a direct unmanaged call. For C# and JavaScript, there is a thin managed layer to "map" the calls into WinRT. However, the managed layer is much thinner than before. It is simply because most of the previous .NET libraries are now WinRT libraries, and these are unmanaged.
For the C# developer however, you will not notice that the WInRT are unmanaged (except in some rare occasions) because the API is managed.
This means that the performance gain in C++ is not going to be as significant as versus "classic .NET". There will be however a small performance gain in using XAML/C++.

Portability of Metro style apps

HTML/CSS/JavaScript applications coded for WinRT are not cross platform. They are something new. They use WinRT specific APIs, both in HTML/CSS (for instance the new Grid layout, which is not supported by other browsers at this time), or of course any calls against the WinRT APIs. This is NOT web programming. This is a standalone Windows 8 app that happens to be coded in a programming language that can also be used on the web. Two very different beasts, though of course knowledge and skills can be leveraged.
XAML/C# apps are not Silverlight or WPF. They are something new. They use WinRT specific APIs (sounds familiar?). Mostly, these APIs were already available in Silverlight, however there was a rather large "spring cleaning" operation, and a lot of APIs were moved in different namespaces, and sometimes renamed. A good example of this is the System.Threading.Dispatcher class which is now a Windows.UI.Core.CoreDispatcher. The original dispatcher's CheckAccess() method is now a property named HasThreadAccess.

In both these points, notice how similar the experience is for the developer: Much is familiar, some things are new (most significantly new/renamed APIs), skills are portable but there is a learning curve.

How to choose?

In Jason Zander's (and others') own words, to choose the stack of choice to create a new Metro style app, you should consider the skills you have. If you are a web programmer with a solid experience in JavaScript, it's obvious that you want to leverage your knowledge of the language. You will have a learning curve though, to learn the new proprietary APIs. If on the other hand you are a Silverlight/WPF developer, or even a .NET developer with no prior XAML experience, it will be easier and more faster for you to climb on the C#/XAML stack. Finally, if you are a C++ enthusiast, the C++/XAML stack is for you. And if like me you love to learn new things, then you can try one or both of the other stacks to build new apps.

Because of the Win8 architecture, any new feature added to WinRT will (almost) automatically be available to all three programming stacks (in fact it requires a little bit of work to decide what should be exposed or not, because some APIs just don't make sense with a given programming language, but in regards to the investment needed to implement the feature, this is not significant.

What about existing applications?

It means that your (our) investments in any technology you were using until now are safe for a number of years. You had a Silverlight application, or are currently working on one? You should continue. WPF? Same thing. Not only these frameworks are fully supported and extended (Silverlight 5 release candidate was announced a few days before Build started), but they also work as is, without any changes on Windows 8.

And C#?

I had the immense privilege to be invited to a side session with Anders Heljsberg, the father of C#. It was a great session, and you can feel Anders' happiness and enthusiasm. WinRT currently supports C#5, including all the new features such as the async and await keywords, and more. When asked if he was thinking of a version 6, Anders laughed and told us that he had a history of being quite stable at his job (13 years at Borland, 10+ years at Microsoft) and that he was foreseeing C# 6, 7, 8. C# is actively developed, and Anders is an accessible architect, who will listen to requests for new features. Changing a language is obviously not a fast process (nor should it be!) but his team is working on exciting stuff, and we are his customers!

Thoughts about porting applications from Silverlight/WPF to WinRT

This one is a tough one, mostly because I did not have time to experiment enough. If you have an existing application implemented in Silverlight or WPF, and you want to make it a WinRT application, how should you proceed, and is that easy?

Based on what I saw and what others reported, it is not a trivial process, even if in most cases the major work is to find out what was renamed and what was moved (see the “spring cleaning” mention above). If you want/have to do that work, I would consider the following:

Why do you want to do this? Do you really want to make your existing application (which by the way runs perfectly fine on the Windows 8 Desktop) a WinRT app? Who are you trying to touch. Shouldn’t you rather be developing a new app, something like a companion to the existing application?
If you answer “yes” to the “do you really want to” question, then I really hope that you followed best practices and layered and componentized your application carefully (I also hope you wrote unit tests, because you’re going to need those to verify that the ported code runs fine).
Porting the code will take some effort. Do not underestimate the effort. I tend to believe that Microsoft was (purposely?) over-optimistic in telling us that this is an easy process. At least now that the documentation is in a very early stage, looking for the renamed objects is a tedious process.
By the way, I started porting MVVM Light to WinRT and I hope that (if my compulsion to blog about Windows 8 lets me) I might have something to share soon.

Tip: I was told (and didn’t test yet) that ILDASM can decompile the WinRT assemblies and let you peek for your objects/methods/properties. This is because even though the WinRT framework is unmanaged, a thin layer of meta data is built in to allow managed code access. Pretty clever (and handy) if you ask me. I (again) didn’t try but I suspect that dotPeek and other similar tools may work too. Let me know in the comments if you try it!

Wrapping up

There are a few not-very-well organized thoughts on Windows 8, WinRT, XAML and more, put together after 5 days of immersion and tons of discussions with Microsoft employees as well as third party experts. I hope you'll forgive me if it sounds a bit chaotic, it is simply that a new framework of that amplitude will need a few weeks (months?) to be fully assimilated and digested. I hope that this helps painting a clearer picture however.

If there is one thing only you should take from this post, it is the following: Don't panic. Yes we will have some work to fully climb on this new exciting platform. But much MUCH of what we know is going to apply almost 1:1 to the new stack. Also, Microsoft is really investing in user experience, Blend, XAML, C# and all that. If there is only one session of Build that you must see, it is Jensen Harris fantastic Big Picture session about the Windows 8 UX.

I for one am pretty excited about Windows 8 and WinRT. First it confirms what I have been thinking since I started playing with the Avalon bits: XAML is a great way to build a wonderful user experience, Blend is central to that experience and C# is awesome. I am also excited to see new ways to develop applications for WinRT, because diversity is good. The Samsung slate is an awesome device, and there was a great sense of excitement in Anaheim this week. Of course I am known for being an optimistic, but I don’t think it’s just me feeling that excitement. Windows 8 is going to be pretty awesome.

Credit for “Don’t panic” button: http://www.flickr.com/photos/brighton/2153602543/s

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

MVVM Light V4 beta1

Laurent Bugnion — Mon, 12 Sep 2011 16:00:20 GMT

This morning, I published MVVM Light V4 beta1 in the form of an MSI. The installation instructions are detailed on the MVVM Light installation page. Please make sure to uninstall previous versions before you install V4 beta1.

There are quite a few changes in this version, and I plan to blog about various features in the coming days. As usual, stay tuned!

Change log

General changes

Added XmlnsDefinitionAttribute for GalaSoft.MvvmLight.Command in Extras assembly.

Setup

Created an installer.

Messenger

Fixed Issue #7521: race condition in Messenger.Default.
Fixed Issue #7539: Messenger support for uncast objects.

ViewModelBase

Added support for RaisePropertyChanged(null) and RaisePropertyChanged(string.empty). A blog post about this will follow.
Fixed Issue #7520: RaisePropertyChanged() fails in ReleaseBuild. This overload was removed because of the many issues, and replaced by the Set methods.
Added Set(...) methods. A blog post about this will follow.

RelayCommand

Fixed Issue #7522: used deprecated Predicate instead of Func.
Fixed Issue #7534: RelayCommand has security issue.

SimpleIoc

Implemented method IsRegistered<T>(). A blog post about this will follow.
Fixed issue "Contains<T>() is returning true even if no instance was already instantiated". Contains<T>() only returns true if an instance is already created. IsRegistered<T>() returns true if the class has been registered with the IOC container.
Fixed issue "Instances get created at registration already when registered with a key and a factory". Registering the instance does not execute the factory method yet. The method is only executed when the method GetInstance is called the first time.
Fixed issue "Use the correct DLLs for CommonServiceLocator". The original DLLs from http://commonservicelocator.codeplex.com are now used everywhere.

DispatcherHelper

The class was moved from GalaSoft.MvvmLight.Extras.dll into GalaSoft.MvvmLight.dll.

Project Templates

A couple of internal changes to the template's structure.
Using the new slightly modified MVVM Light logo.

ViewModelLocator Template

Modified template to use SimpleIoc.
A couple of internal changes to the template's structure.
Using the new slightly modified MVVM Light logo.

ViewModel Template

A couple of internal changes to the template's structure.
Using the new slightly modified MVVM Light logo.

View Template

Fixed issue in XAML for WP7 and WP7.1 templates.
A couple of internal changes to the template's structure.
Using the new slightly modified MVVM Light logo.

INPC snippet

Setter in property is now public.
Added $end$ marker.
Added new snippets with various ways to call RaisePropertyChanged.
Added a snippet using the new ViewModelBase.Set() method.
A blog post will follow about all this.

ViewModelLocator property snippet

Added $end$ marker.
Modified to use SimpleIoc.

Relay Command snippets

Added code snippets for RelayCommands. A blog post about this will follow.

Details

XmlnsDefinitionAttribute for GalaSoft.MvvmLight.Command in Extras assembly

Thanks to the addition of XmlnsDefinitionAttribute, you can simplify the inclusion of the MVVM Light EventToCommand action in XAML. See the before and after below:

Before:

<UserControl xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:i="http://schemas.microsoft.com/expression/2010/interactivity" 
             
             xmlns:cmd="clr-namespace:GalaSoft.MvvmLight.Command;assembly=GalaSoft.MvvmLight.Extras.SL4"
             
             xmlns:cmd="http://www.galasoft.ch/mvvmlight" 
             x:Class="MvvmLight4.MainPage">

After:

<UserControl xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:i="http://schemas.microsoft.com/expression/2010/interactivity" 
             xmlns:cmd="http://www.galasoft.ch/mvvmlight" 
             x:Class="MvvmLight4.MainPage">

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