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.
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.
To fix the bug, simply download V3.0.3.19 from Codeplex and install. You don’t need to uninstall the previous version.
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
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.
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.
For Windows Phone projects only, in addition:
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 ‘}’.
Apologies for this bug, and thanks to everyone who reported it and helped make MVVM Light better.
Cheers, Laurent
I just pushed two big updates to MVVM Light setup components.
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.
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:
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
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).
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
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!).
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.
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.
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
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!.
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.
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)!!.
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!
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/.
There are a few restrictions around the 3D rendering, for security reasons. I am still sorting out exactly what they are (the last time we heard about these restrictions, it was a relatively early build and I need to check what is the status in the latest and greatest).
Also, like previously, COM access does not work and as I mentioned above, p/invoke is also only available on Windows. Both these features require elevated permissions by the way.
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!
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!
The steps to create the application and the WCF service are 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.
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.
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:
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.
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.
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):
Hopefully the confusion around this is cleared now. In summary:
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.
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.
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”.
Almost all MVVM Light components are also available in the Windows 8 version. The ported components are:
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:
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.
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!
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.
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.
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.
Ads by Lake Quincy Media