Plenty of Silverlight developers were concerned that their investment in the technology would end up being worthless. I never really understood that since I've always believed that good developers focus on skills that are transferable to multiple technologies instead of betting it all on a single technology. Nevertheless, many Silverlight developers were up in arms, but their worries and fears seem to have been calmed by the news that Windows 8 will make extensive use of XAML. Silverlight developers will be able to transfer their XAML skills to building Metro apps and of course, WP7 apps. And there's no reason to assume that Microsoft intends to change its smartphone platform in a way that would diminish the importance of XAML. So, Silverlight developers who were worried that their skills will be worthless don't really have anything to worry about and I'm sure many of them are quite relieved by that. After all, many Silverlight projects will be able to run as native apps on Windows 8 with relatively minor modifications.

Of course, that doesn't quite offer a solution to the thorny little issue about all the Silverlight projects that have been developed because of some of the benefits that Silverlight promised: cross platform and browser-independent availability of the plugin. The promise was that you could develop projects that would be available to users no matter what platform or browser that they were using (believers of this promise would even mention Moonlight, which has never really offered a truly compatible version), and with no deployment-related issues. After all, users only needed to have the Silverlight plugin installed to run your software. And that promise has been broken. Yes, you can migrate your Silverlight projects to Windows 8. Yes, people will be able to keep running existing Silverlight projects as long as they have the upcoming Silverlight 5 runtime installed. But we also already know that the Metro version of IE10 will not run the Silverlight plugin and that running the plugin in the 'desktop' version of IE10 will require users to install it themselves. For enterprise software, that's not much of an issue but you do have to ask yourself: how long are you willing to hang on to a plugin that Microsoft itself is no longer interested in improving in the long run?

The reality of the matter is that your Silverlight products only have a future if you convert them to WinRT so they can run on Metro natively. Which means you've lost the ability to reach users on multiple platforms and devices. The very same technology you picked because of its cross-browser and cross-platform benefits has forced you on a path where in the future, you can only target users on the Windows platform meaning either Windows 8 or WP7. Sure, you can hang on to the fact that the plugin will be available for a few more years, but that also is a limiting choice since an ever increasing number of users will be running iOS and Android, and there's no reason whatsoever to expect the plugin to actually run on those platforms. Hell, WP7 doesn't even have the Silverlight plugin for its browser. My previous employer pretty much bet it all on Silverlight, mostly because they didn't want to deal with HTML/JavaScript, but also because they thought it would eventually be available on all devices. Which essentially means they're stuck with a couple of products that only really have a long-term future on Windows 8 or WP7, and its subsequent versions. Unless of course, current promises about said platforms are broken again. Yet another reason to start taking open standards and technologies that have multiple stakeholders seriously, I suppose.

Surely, if the core audience of one of their most-touted technologies of the past years started to doubt the future of their platform so openly, a response to calm down the fears would have to be forthcoming, no? The only Microsoft employee to respond was Pete Brown, and i thought it was quite telling:

You all saw a very small technology demo of Windows 8, and a brief press release. We're all being quiet right now because we can't comment on this. It's not because we don't care, aren't listening, have given up, or are agreeing or disagreeing with you on something. All I can say for now is to please wait until September. If we say more before then, that will be great, but there are no promises (and I'm not aware of any plans) to say more right now. I'm very sorry that there's nothing else to share at the moment. I know that answer is terrible, but it's all that we can say right now. Seriously.

Followed by:

Guys, I've been pretty clear that my hands are tied here, so don't read anything more into my lack of comments than that. We simply aren't allowed to say anything about this. It's not that we have nothing to say. It's not that we don't care. It's not that I personally don't care, because I do, a lot.

And finally:

This whole thing has blown way out of proportion. Base your information on our primary sources (like our press release), not on third party speculation. That's not to minimize how everyone feels, but keep in mind that Windows 8 itself is still a ways off from retail, and even much further away from internal IT adoption. The 8 weeks until //build/ is a pretty small amount of time to wait in comparison. Take some vacation time this summer, and look forward to the //build/ conference. Stop speculating based on just a small demo of some very cool new technology. Tell your management to do the same: if they're basing your project work for the next X years on the results of a quick demo for an unreleased operating system, then they are doing you and your company a real disservice.

If i were still a Silverlight developer, i'd find the final sentence quite insulting. If anything, Microsoft is doing a sizable portion of their customers a disservice by being so unclear about the future of one of their technologies. This certainly isn't the first storm to come up about Silverlight's future, and every time people have openly questioned the future of the platform Microsoft has responded rather softly. There's never been a convincing and strong "we are fully committed to making Silverlight a smart choice for the future" kind of response. And this time, no response at all. Just silence. Deafening silence even, because of Pete's remark that they are not even allowed to talk about it. Once again, the Silverlight community is screaming for a real response and they're being ignored. They're being told to wait until September.

Obviously, i don't know what Microsoft is planning for Silverlight, but i really have difficulties understanding how any company could still trust it as a viable technological choice. First the mixed messages, then the clear favoritism Microsoft is showing towards HTML5 and JavaScript (which, IMO, is justified but that's another topic), and now the unwillingness to stand up for one of their products that is being doubted so openly, for the first time by its very users who only want assurance of Microsoft that their investments in the technology haven't been a total waste. I took a lot of flack from the Silverlight community when i scored Silverlight so low in the 'strategic' department in my post where i detailed how we came to the conclusion to go with HTML(5) instead of Silverlight but this recent PR fiasco kind of validates that score IMO.

However, Microsoft certainly isn't the only one to blame here. If you read the thread i linked to, you'll see some reactions from people who've pretty much put all of their eggs in the Silverlight basket and are now reacting angrily towards Microsoft. If any of those people are reading this, allow me to quote myself from 2 posts that i wrote over 6 months ago:

If however, your product is supposed to become the basis of your long-term success, then the choice of Silverlight over HTML/CSS/JavaScript is short-sighted and ultimately flawed for a number of reasons. The first of which is that Silverlight is a proprietary technology in the worst possible way. Its future will be determined by a single company who naturally hold their own best interest at heart, and not yours. As long as it makes sense for them to keep improving Silverlight, they will and you can benefit from that. As soon as it no longer makes sense for them, the technology will become increasingly irrelevant. Obviously, that is a risk that you face with any kind of technology. Sticking with open standards and open source software might very well result in the same outcome but there is one tremendously important difference here: with Silverlight, you have no migration path.

That quote was from 'Keep Your Eyes On The Road', written in September 2010. And the next quote is from 'Developers Shouldn't Specialize', written in October 2010:

There's also another factor to keep in mind, which is more important than you might realize. If you specialize in technology from commercial vendors, you need to keep the market forces in mind that could influence the vendor. Those market forces might be (or seem) irrelevant to you, but the vendor will not let that influence its decisions and strategies if the vendor itself is competing with other companies on a much larger level than your company or your clients are. And when a vendor changes tactics due to market forces, the technology you've chosen to specialize in might be on the way out, or it might no longer be the hot new thing that you can capitalize on. And that is where one of the biggest dangers in specialization lies. If you're specialized in a specific technology, you're personally invested in it. Your current standard of life, your livelihood, depends largely on that specific technology. Sure, you can move on to something else but you will have to get used to less than you're used to, probably both in money and stature for a while. Realistically speaking, odds are high that you are emotionally attached to this technology because of this. When you are confronted with bad news regarding the technology's future, you're likely to exhibit classic denial symptoms. The recent news about the Silverlight strategy shift and specifically the reactions to it, is a beautiful example of this.

Anyone who's upset at Microsoft about this has only himself to blame. You've put yourself in this position, because the writing has been on the wall for a while now.

In this post, i want to go over the categories of criteria, and discuss our findings. I'm also going to share the spreadsheet so you can go through the numbers yourself. Depending on your needs or your opinions, you can change the weights and the scores and see how that affects the outcome. I removed some of the criteria that were specific to my client, but it didn't have a significant impact on the outcome. For this post, I also limited the candidates to ASP.NET MVC 3 in combination with the jQuery family (jQuery Core, jQuery UI and jQuery Mobile) and Silverlight.

Here's a quick listing of the categories and some of their criteria (for the actual list, check the spreadsheet... the link is at the end of the post):

• User experience (compelling UI, accessibility, intuitive/ease-of-use, accessible from multiple devices, accessable from multiple platforms)
• Infrastructure (easy/flexible deployment, monitorability)
• Security (safe from XSS, CSRF)
• Performance (server footprint, client-side resource usage, asynchronicity, UI responsiveness, initial load times)
• Code/Architecture (maturity, reusability of validation logic, simplicity, maintainability, flexibility, power, testability, i18n, feedback cycle, learning curve, potential efficiency, rapid application prototyping, readable URLs, extensibility)
• People (limits the number of required skills, mindshare, documentation, community support, commercial support)
• Strategic (future-proof, standards-compliant, differentiator, backing, vision)
• License (do we have access to the code?)
• Cost
• Tools (IDE support, availability of extra tools, free 3rd party component availability, commercial 3rd party component availability

Depending on what you or your organization requires, some of these might not apply to you. Perhaps there are other criteria that you find important and that we missed. Nevertheless, i think this is a pretty comprehensive list which covers most of the factors that you need to think about when making this kind of decision.

This graph visualizes how both technologies scored, grouped by category:

I'm sure there are quite a few things about that image that surprise you. The first thing you might be thinking is "how can Silverlight score so badly when it comes to User Experience?". The answer to that is quite simple: if your users aren't using a desktop/laptop with Windows or OS X on it, there is no experience to be had at all. Users that require assistive technology are out of luck as well since accessibility support in Silverlight is still very poor. If you hold those factors into account, it really doesn't matter much that you can easily make Silverlight applications incredibly flashy (pardon the pun). Besides, most people get bored and annoyed with excessive animations rather quickly, so you're often better off not to overdo it. With that in mind, jQuery UI and HTML5 will easily meet your needs for that kind of stuff.

Another area where Silverlight scores very poorly is the strategic department. The fact that it's not standards-compliant obviously hurts a lot here, but there's more to it than that. First of all, the mobile story (again) pretty much kills it. Android and iOS don't support it. We already know it's never going to work on iOS and as long as it doesn't work on iOS, Android has no reason whatsoever to provide support because Silverlight simply isn't important in the grand scheme of things to any of the important players. Microsoft hasn't even announced a Silverlight browser plugin for WP7 yet and who knows if it will? That means that Silverlight web applications aren't usable on any mobile device right now, except for slates running a full Windows OS which looks like its only a tiny portion of the market. Secondly, despite its original tagline of "Lighting up the web", it appears that Microsoft only has about 3 scenario's in mind where it still actively pushes Silverlight: internal business applications, video streaming and native WP7 development. While internal business applications are certainly a large part of what we're going to do in the next couple of years, we're also going to build things that are available publicly and to a large variety of people. Going with Silverlight for the internal applications and HTML(5) for the public-facing applications wouldn't be very cost-efficient either since that means we have to train our developers for both cases. And it wouldn't make much sense anyway since HTML(5) is a great fit for internal business apps as well.

But, as you can see, there are areas where Silverlight scores better than ASP.NET MVC 3 with jQuery. For instance, when it comes to Tools, you can't deny the fact that Visual Studio and Blend cover a lot of ground when it comes to the whole Silverlight developer experience. At the very least, you can mostly stick to your familiar integrated environment, whereas with standards-based web development, you're likely to spend some time in Firebug or Google Chrome's developer tools instead of sticking almost entirely with Visual Studio. I personally don't mind (at all actually) to use other tools than Visual Studio, but there are quite a few .NET developers who do prefer to stick with Visual Studio. Which brings me to the People category. The biggest benefit that Silverlight has over standards-based web development is that you only need to know C# and XAML. With standards-based web development, you have to know HTML, CSS, JavaScript and the language of your server-side technology, in this case also C#. This might impact your ability to find new developers so Silverlight does have sort of an advantage there. Though i'd argue that you're better off in the long term with people who are willing to step out of their comfort zone instead of clinging to what they know. From a security point of view, Silverlight also scores better because you don't really have to worry about common issues such as XSS, CSRF and other vulnerabilities that are common in web-development.

So we have 3 categories where Silverlight scores better than ASP.NET MVC3/jQuery but that's far from sufficient to close the gap. Based on the weights we assigned to the criteria, the maximum possible score is 732. ASP.NET MVC3 with jQuery scored 568. Silverlight scored 304. Obviously, the results will vary depending on what you find important. Which is why we asked an analyst from one of those large IT research & advisory companies to give us some feedback on this. The analyst agreed entirely with our findings and our data, and confirmed that his company is recommending moving towards HTML5 to all of their customers. He even went as far as to say that Silverlight is hard to recommend, unless you're not targeting any mobile users and the applications are internal-only and you've already invested in the technology. I can't provide a link for any of this yet, but a paper about this will be published soon so i'll either link to it when it's out (if it's publicly available) or at least reference it.

I encourage anyone who is faced with the same decision to use the spreadsheet and modify it to your needs (adding more criteria, changing weights and/or scores, whatever) to see which one is the best fit for your situation. You can download the spreadsheet here.

I asked Bob Muglia, the Microsoft President in charge of the company’s server and tools business, that very question and got what I consider to be the clearest answer yet about how Microsoft is evolving its Silverlight strategy. “Silverlight is our development platform for Windows Phone,” he said. Silverlight also has some “sweet spots” in media and line-of-business applications, he said.

It's the development platform for Windows Phone (more on that in a minute). It has some sweet spots in media and business apps. Things sure can change a lot in a short time. Silverlight was at first positioned as an ideal technology for media. After that, it was increasingly being marketed as a great platform to develop business applications, cross-platform ones even. Now, despite the fact that nothing has been taken away from the platform's capabilities, it has some "sweet spots" in both areas where it was supposed to be a great technological choice. Every single feature or capability that once formed Microsoft's message that it was great for business applications is still there. And they won't take that away either. The mere fact that their message about Silverlight has transformed so much now, is incredibly telling. If you're a Microsoft customer who's invested a lot in Silverlight for business applications, you have some pretty good reasons to be upset about this.

After all, given how the stated goals of Silverlight have evolved in the past 3 years, who's to say those "sweet spots" will remain interesting enough for Microsoft? I have no doubt that they're going to heavily invest in making Silverlight a great development platform for Windows Phone (whether they will succeed at it is an entirely different matter though), but what you need to develop great mobile applications differs a lot from the needs you have when building great business applications. Will the needs of developers using Silverlight to create business applications be met by Microsoft? Let me rephrase that: keeping the manner in which they're now promoting HTML5 in mind, will they also keep putting additional resources into improving some niche areas of a technology who's primary purpose is to facilitate mobile development? Maybe they will. Maybe they won't. I sure as hell wouldn't bet on it.

Now, unlike a lot of people, i don't think that Silverlight is dead. Far from it even. Silverlight has a future as long as Windows Phone has one. Its real future lies in the mobile world now, and no longer in the browser or on the desktop. It's going to keep working in your browsers, and its going to keep working on your desktops. But you really need to wonder how many of the needed improvements for those 2 environments you'll see being introduced to Silverlight, and how long it'll take. It's quite reasonable to assume that improvements in Silverlight which target the mobile development story will be receiving higher priorities than those which target the browser or desktop development model. After all, that is what the new Silverlight strategy implies. And given Microsoft's need to conquer a respectable position in the mobile world, and their ever increasing support of HTML5, it only makes sense for them to do so.

As for Silverlight being a suitable platform for mobile development, i can't help but wonder whether it really can live up to the high expectations that people will set on it. Anyone who's done any serious Silverlight development knows that it is a technology which suffers from a lot of memory usage problems. Partly because there are quite a few memory leaks in Silverlight's own controls, but also because the Silverlight programming model easily leads to a lot of dangling references which will lead to serious memory problems in a memory constrained device such as a mobile phone. Unless they get rid of the memory problems very quickly, i can easily see Windows Phones suffering from a lot of problems as people start using more and more 3rd party applications on their phones simultaneously. Well, it would have to support running multiple applications simultaneously before it'll be a real problem, but you know that's only a matter of time.

So, as for me personally, i don't really have a lot of belief left in Silverlight as a technology. I don't see it advancing much more in the browser or on the desktop, and i think it's got some real, difficult challenges ahead in the mobile world. What do you think?

To give you an idea of what kind of leaks that keep popping up, be sure to check out these links: http://forums.silverlight.net/forums/t/179177.aspx http://forums.silverlight.net/forums/t/179358.aspx http://forums.silverlight.net/forums/t/180702.aspx http://forums.silverlight.net/forums/t/181257.aspx http://forums.silverlight.net/forums/t/171739.aspx

If anyone from Microsoft reads this: please, pretty please, pretty please with sugar on top: can we get a little bit more QA from you guys? If you can put out products like WebMatrix and LightSwitch, than surely you must have enough resources available to make sure that your real development platforms do not become a cost-sink for your customers due to your own lack of quality control, no?

Update: it's also quite telling that the search phrase "silverlight memory leak" is the number one search phrase through which people get to this site. #justsaying

If you're doing Silverlight or WPF, you've no doubt come across the MVVM (Model-View-ViewModel) pattern. It seems to be the most popular client-side architecture pattern used among Silverlight/WPF developers. I find the pattern to be highly overrated, and actually have some big issues with the whole thing.

First, let's briefly cover what MVVM is about for those of you who don't know yet. MVVM virtually eliminates all of the code that would typically be placed in the code-behind file of your View (a user control, a screen, whatever) by putting all of that logic in the ViewModel. The ViewModel itself is never tightly coupled to the View. If it does have a reference to it, it's typically through an interface that the View implements instead of a reference of the actual type of the View. This increases, or better yet, introduces testability to a large part of your UI code that you normally wouldn't be able to cover with unit tests if you'd go with the traditional "put it all in the code-behind"-approach.

The ViewModel typically contains properties for the data that is to be shown in the View, and also raises notification events when the data in those properties changes. The View uses the powerful data-binding capabilities of Silverlight/WPF to bind the properties of the ViewModel to other user controls that the View is composed of. User-events that are captured by the View are sent to the ViewModel through Commands. Typically, these commands execute a method in the ViewModel which contains some kind of logic... usually to either send the updated data in the ViewModel's properties to the Model (usually a Service Layer in Silverlight, in WPF it could be either a true Domain Model or also a Service Layer), to perform some business logic in the Model, or to retrieve data from the Model so it can be placed in the ViewModel's properties so the View can bind to it.

That is, in a nutshell, how the MVVM pattern works. So why do i have issues with this? You can develop and test most of the application's logic without being dependent on a physical View and that is typically a Good Thing, no? It sure is! However, my problem with this approach is that too many responsibilities are concentrated within the ViewModel. Its main responsibilities are to facilitate databinding and to interact with the Model. And that, in my opinion, isn't very clean. In some ways, you could actually think of the ViewModel as a glorified code-behind, with the only difference being that it's not tightly coupled to the (physical) View.

In most (if not all) MVVM implementations, a ViewModel has many possible reasons to be changed. It might need to be changed because of different data-binding requirements. Then again, it might also require changes when a part of the Model is modified. Now, i'm sure many of you can agree with me when i say that two of the most important principles in software development are Seperation of Concerns (SoC) and the Single Responsibility Principle (SRP). Obviously, the ViewModel doesn't fare well when it comes to both of these principles.

Lets forget about MVVM for a second and focus on the concerns and responsibilities that a user control can have... say, a user control that shows customer information and allows the user to edit that data so it can be persisted:

• visualization of the actual control (its own layout as well drawing other user controls that it is composed of)
• communication/interaction with the Model
• making data (from the Model) available so it can be displayed
• outputting data in the correct user controls (for instance: various textboxes)
• (simple validation) of modified/inputted data (for instance: no string values for numeric fields, etc...)

Without MVVM, all of these would be taken care of in the View. Obviously, not a good idea right? After all, if it were a good idea, we'd never have had a reason to start using MVVM in the first place.

Now, with MVVM, a lot of people would divide these concerns and responsibilities like this:

View:

• visualization of the actual control (its own layout as well drawing other user controls that it is composed of)
• outputting data in the correct user controls (for instance: various textboxes)
• (simple validation) of modified/inputted data (for instance: no string values for numeric fields, etc...)

ViewModel:

• communication/interaction with the Model
• making data (from the Model) available so it can be displayed

In this case, the View still has 3 responsibilities which is still too much according to 'the guidelines', but it's not that big of a deal (though plenty of people would argue that the simple validation would be better placed in the ViewModel). You're highly unlikely to actually want to write automated tests for pure visualization anyway and the SRP is not something that you absolutely need to follow to the extreme in every single place. For the View, this is really not a problem and very much acceptable.

The ViewModel however has 2 important responsibilities in this case, and i'd argue that these 2 things should not be done in the same place. Making data available is done through data-binding. To do this, you need a set of properties and you need to raise the necessary events. In most cases, raising those events is very straightforward, but in more complex controls you might need a bit of additional logic to determine which event should be raised at what point. The other important responsibility is the communication/interaction with the Model. In most Silverlight applications, the Model will be a Service Layer. To communicate with this Service Layer, you need Service Proxies. That means that your ViewModel is essentially responsible for communicating with the Service Layer, dealing with business exceptions that might be thrown by some service calls, and dealing with technical exceptions that can occur simply because of network-related problems. Group all of those together and i don't think i'm going out on a limb here by saying that that is a lot of logic to put in one class, no?

(Sidenote: what i don't really understand is that many people who vigorously advocate adherence to SRP and SoC in their domain and business code don't seem to hold their UI code to the same standards. I do.)

At work, we do a lot of Silverlight development. We typically have around 5 Silverlight projects in active development at the same time. And it's been that way for over a year now. That equals a lot of Silverlight code that we've written and experience and knowledge that we've built up. And we haven't used MVVM for any of it. All this time, we've been using the MVP pattern (Supervising Controller variant) with a slight twist. That twist being a slimmed down version of a Presentation Model. Our Presentation Model's sole responsibility is to facilitate data-binding, and in some cases, a touch of validation is added as well.

If we go back to our previous example of the customer screen, the responsibilities and concerns would be divided like this in our MVP-PMlight approach:

View:

• visualization of the actual control (its own layout as well drawing other user controls that it is composed of)
• outputting data in the correct user controls (for instance: various textboxes)
• (simple validation) of modified/inputted data (for instance: no string values for numeric fields, etc...)

Presenter:

• communication/interaction with the Model based on the contents of the Presentation Model

Presentation Model:

• making data (from the Model) available so it can be displayed

Which leads to classes which are more focused on their task instead of trying to focus on too many things at the same time. In my opinion, this approach is much better/cleaner than MVVM. Not only is there a noticeable benefit in code quality (classes are more focused), there is also increased potential to reuse our 'light Presentation Models' in multiple controls. Testability is increased over MVVM as well since it's always easier to test classes which are focused versus testing classes which have too many responsibilities. All in all, a couple of important benefits and we still haven't thought of a real drawback compared to MVVM.

Those are Silverlight tests, executed through Resharper within the Silverlight runtime

This is something that Steven De Kock and Tom Ceulemans (two coworkers of mine without a blog, so no link) have been working on.  Those are Silverlight tests, executing in the Silverlight runtime, within a full browser context.

And yes, they will release it as an open source project soon

First of all, you need to make sure that your IIS installation has support for Windows Authentication. Go to Add/Remove Programs (appwiz.cpl), click on Turn Windows Features on or off, select Internet Information Services - World Wide Web Services - Security and make sure that Windows Authentication is checked.

Next, you need to make sure that the virtual directory where you're hosting the WCF service has Windows Authentication enabled. Open Internet Information Services Manager (inetmgr), select the virtual directory where the WCF service is hosted, click on the Authentication icon and enable Windows Authentication.

After that, you need to add the following to the binding configuration of the service endpoint (in the host, obviously):

          <security mode="TransportCredentialOnly">
            <transport clientCredentialType="Windows" />
          </security>

I only got it working with basicHttpBinding, so unfortunately i can no longer use the customBinding to use binary XML...

In your Silverlight project, open the ServiceReferences.ClientConfig file and add the following to the binding configuration:

          <security mode="TransportCredentialOnly" />

After that, you should be able to do this in your WCF service:

            WindowsIdentity myuser = ServiceSecurityContext.Current.WindowsIdentity;

And that should return the Windows user of the user running the Silverlight client.

For the record: this is with Silverlight 3... i have no idea if it'll work with Silverlight 2

But these views do have to interact with each other. I didn't want to use typical events because that would require either a certain view to know about another view to be able to subscribe to its events, or you'd need some other component which knows which views need to be hooked to each other. We really need maximum flexibility for what we have in mind with our views, so it only made sense to finally start using the Event Aggregation pattern. The idea is that a view can basically publish events, without knowing who is subscribed to these events, and that suscribers will be notified whenever these events occur. However, subscribers don't know anything about who is publishing the events. Instead, both publishers and subscribers only know of the Event Aggregator. A publisher tells the aggregator to publish an event to all subscribed listeners for that event. Each subscribers simply tells the aggregator "i'd like to be notified whenever this event occurs, and i don't care where it comes from".
Plenty of implementations of this pattern can be found online already, so i figured: why not add my own? :p

Fist of all, an event is nothing more than a class that inherits from this class:

    public abstract class Event {}

Every event should inherit from this class, and add whatever necessary properties that are important for that particular type of event.

If a class is interested in listening to a specific event, it needs to implement the following interface:

    public interface IListener { }
 
    public interface IListener<TEvent> : IListener
        where TEvent : Event
    {
        void Handle(TEvent receivedEvent);
    }

If a class is interested in multiple events, it simply needs to implement the generic IListener interface for each type of event that it wants to handle.

Then we obviously need the Event Aggregator. I wanted an aggregator that allowed listeners to either subscribe/unsubscribe to/from very specific events, or just subscribe/unsubscribe to/from whatever it supports. So i have the following IEventAggregator interface:

    public interface IEventAggregator
    {
        void Publish<TEvent>(TEvent message) where TEvent : Event;
        void Publish<TEvent>() where TEvent : Event, new();
 
        void Subscribe(IListener listener);
        void Unsubscribe(IListener listener);
 
        void Subscribe<TEvent>(IListener<TEvent> listener) where TEvent : Event;
        void Unsubscribe<TEvent>(IListener<TEvent> listener) where TEvent : Event;
    }

The Subscribe and Unsubscribe methods that simply take an IListener reference will either subscribe or unsubscribe the given listener to/from every event that it can handle. In other words, for every generic IListener interface that it implements. Yet you also have the ability to subscribe/unsubscribe from a specific event type.

And here's the implementation:

    public class EventAggregator : IEventAggregator
    {
        private readonly object listenerLock = new object();
        protected readonly Dictionary<Type, List<IListener>> listeners = new Dictionary<Type, List<IListener>>();
        private readonly IDispatcher dispatcher;
 
        public EventAggregator(IDispatcher dispatcher)
        {
            this.dispatcher = dispatcher;
        }
 
        public virtual void Subscribe(IListener listener)
        {
            ForEachListenerInterfaceImplementedBy(listener, Subscribe);
        }
 
        public virtual void Unsubscribe(IListener listener)
        {
            ForEachListenerInterfaceImplementedBy(listener, Unsubscribe);
        }
 
        private static void ForEachListenerInterfaceImplementedBy(IListener listener, Action<Type, IListener> action)
        {
            var listenerTypeName = typeof(IListener).Name;
 
            foreach (var interfaceType in listener.GetType().GetInterfaces().Where(i => i.Name.StartsWith(listenerTypeName)))
            {
                Type typeOfEvent = GetEventType(interfaceType);
 
                if (typeOfEvent != null)
                {
                    action(typeOfEvent, listener);
                }
            }
        }
 
        private static Type GetEventType(Type type)
        {
            if (type.GetGenericArguments().Count() > 0)
            {
                return type.GetGenericArguments()[0];
            }
 
            return null;
        }
 
        public virtual void Subscribe<TEvent>(IListener<TEvent> listener) where TEvent : Event
        {
            Subscribe(typeof(TEvent), listener);
        }
 
        protected virtual void Subscribe(Type typeOfEvent, IListener listener)
        {
            lock (listenerLock)
            {
                if (!listeners.ContainsKey(typeOfEvent))
                {
                    listeners.Add(typeOfEvent, new List<IListener>());
                }
 
                if (listeners[typeOfEvent].Contains(listener))
                {
                    throw new InvalidOperationException("You're not supposed to register to the same event twice");
                }
 
                listeners[typeOfEvent].Add(listener);
            }
        }
 
        public virtual void Unsubscribe<TEvent>(IListener<TEvent> listener) where TEvent : Event
        {
            Unsubscribe(typeof(TEvent), listener);
        }
 
        protected virtual void Unsubscribe(Type typeOfEvent, IListener listener)
        {
            lock(listenerLock)
            {
                if (listeners.ContainsKey(typeOfEvent))
                {
                    listeners[typeOfEvent].Remove(listener);
                }
            }
        }
 
        public virtual void Publish<TEvent>(TEvent message) where TEvent : Event
        {
            var typeOfEvent = typeof(TEvent);
 
            lock (listenerLock)
            {
                if (!listeners.ContainsKey(typeOfEvent)) return;
 
                foreach (var listener in listeners[typeOfEvent])
                {
                    var typedReference = (IListener<TEvent>)listener;
                    dispatcher.BeginInvoke(() => typedReference.Handle(message));
                }
            }
        }
 
        public virtual void Publish<TEvent>() where TEvent : Event, new()
        {
            Publish(new TEvent());
        }
    }

In case you're wondering... the IDispatcher interface is merely a way to wrap Silverlight's real Dispatcher. We wrap it so we can use a different implementation of the IDispatcher in our automated tests. Other than that, the implementation is very straightforward.

We started using this very recently, so this implementation might change in the upcoming weeks, but for now it does what it needs to do and it does so pretty well. In our case, every view's Presenter automatically has an IEventAggregator property so whenever we need to publish an event, we can simply do something like EventAggregator.Publish(new SomeEvent(someParameter)). Or, Presenters that need to listen to events can simply say EventAggregator.Subscribe(this) or only subscribe to some specific events whenever they need to and their specific Handle method will be called whenever someone publishes the event. This also allowed us to get rid of the somewhat awkward syntax when testing events (subscription, unsubscription and the actual handing of events) with mocking frameworks.

And as a last bonus, i put a call to the Unsubscribe(IListener) method in the Dispose method of our base Presenter implementation. Which means that none of them will be left subscribed to events by accident anymore

The company where i work has been using Silverlight ever since the first version came out, and by now we have quite a bit of experience and dare i say expertise in it. We generally suggest using Silverlight for every new project that we do, and the only time we don't use it is when customers don't want us to use it. This happens very rarely though.

While i generally don't get involved in most of the UI stuff, i'm pretty happy with this because i seriously like Silverlight as a platform. Below is my list of top 5 reasons why Silverlight is my preferred platform for Web Development nowadays:

1. The ability to create an excellent UIX which definitely matters to customers.

   We have some projects at work where the Silverlight UI definitely receives a "wow" response from customers. Not only because the UI is extremely responsive and snappy, but also because we can use new ways of visualizing data and enabling user actions in the UI in ways that are either completely new for web applications, or just new in general. We can easily create much more intuitive user interfaces with a responsiveness that can easily compete with that of desktop applications.

2. Low bandwidth overhead

   Downloading the XAP file can sometimes be painfully slow, depending on your bandwidth obviously, but once it's downloaded it's also cached by the user's browser. Everything that happens after that consumes very little bandwidth. There is no CSS, no HTML markup, no javascript, ... the only thing that goes over the wire is the data that you actually need. And with Silverlight's Binary XML feature you're also using less bandwidth than before. This might not seem like a big deal to you, but bandwidth has a huge impact on the client-side responsiveness as well as your server-side ability to process requests.

3. The client is stateful again

   This one is huge to me. We don't have to deal with things like ViewState or SessionState or anything like that. If a client has retrieved a set of data, it can just keep it in memory if it makes sense to do so. This is especially useful for things like user-profiles, or static data that never changes but it has an impact on pretty much everything you develop. You can simply keep whatever data you need in memory, and it has no impact on the server at all. Well, it actually reduces the amount of data that you need to send to the server (or receive), and the number of requests you need the server to handle to implement the functionality you need client-side. This is pretty much a win-win for both the client and the server whereas with typical ASP.NET development, either the client or the server has to take some kind of a hit when it comes to maintaining state (even if it's only a little).

4. The ability to write the client almost entirely in C#

   I don't know about you, but my HTML, CSS and Javascript skills are extremely limited. This seriously reduces my effectiveness when i need to make changes in the presentation layer in typical ASP.NET applications. And while my XAML skills aren't what they should be, my C# skills are sufficient for me to be effective in client-side changes. I can easily look at a piece of client-side code and make whatever change i need to make without having to consult a reference guide. That's not the biggest advantage to being able to write the client in C# though. Existing C# skills are very easily transferable to the Silverlight side of things, which means that a larger pool of developers is available to work on your front-end. True, there is a bit of a learning curve when it comes to Silverlight, but i'd argue that there is a much steeper learning curve to doing traditional client-side web development effectively.

5. It's only going to get better

   As much as i like Silverlight, it is by no means perfect and there is plenty of room for improvement. That's normal though for such a young platform. In the future we'll see plenty of new libraries and tools that will become available to Silverlight developers which should enable us to create even better web applications. Microsoft is investing a lot of money and effort into it, and i'm pretty sure that others will follow.

Now, you won't hear me say that Silverlight is the perfect solution for every web application. SEO is still a problem, as well as acceptance of the Silverlight plugin in corporate environments (though this will only improve over time). But, in the situations where you can use Silverlight, it certainly pays off to do so.

I wrote a very simple Silverlight application which has a rather typical memory leak. Here's the actual code:

        public event EventHandler<MyEventArgs> MyEvent = delegate { };
 
        private void CreateNewViewButton_OnClick(object sender, RoutedEventArgs e)
        {
            ViewContainer.Children.Clear();
 
            var newView = new MyView();
            MyEvent += newView.EventHandler;
 
            ViewContainer.Children.Add(newView);
        }

For some of you, the memory leak is already very clear. Like i said, it's a very simple example

Let's go through the process of finding and fixing the memory leak using WinDbg. First of all, download Debugging Tools For Windows (which contains the WinDbg executable) here and install it.

Then we start our application in Internet Explorer (for some reason i can't use WinDbg to inspect the managed memory heap with Firefox, so i just use Internet Explorer for this stuff) and use it. In the case of my example, that means clicking the button which creates a new view a couple of times.

Open WinDbg.exe and select the 'Attach to a Process' menu item in the 'File' menu and select the iexplore.exe process.

Then you need to load the correct version of sos.dll:

After that we can see which types of our MySilverlightApplication namespace are present in the managed heap, including how many instances of them:

As you can see, there are 13 instances of our MyView type present in the heap. Using the value in the MT column, we can drill down further:

This shows the memory address of each instance of the MyView type in the heap. Now we can see if there are any live references to these instances:

This is actually for the first address that was listed. As you can see, it is still a reachable reference, which means it will not be collected by the garbage collector. The chain of references clearly indicates that the instance is still referenced from our event in the MainPage instance. All of the previously listed instances show the same reference chain, so this is clearly a memory leak. Even though we should only have one active reference of MyView at any point in time of this application, the MyEvent event on MainPage clearly keeps each instance of MyView alive.

The correct way to fix this is to make sure that whenever we remove an instance of MyView, we need to unsubscribe it from the MainPage's MyEvent handler. Always remember this rule when it comes to dealing with events: if the publisher of the event has a longer lifetime than the subscriber of the event, then you absolutely have to unsubscribe each subscriber from the event or the publisher will keep references to each subscriber (preventing them from being garbage collected) for as long as the publisher is alive.

Here's the modified version of the above code which avoids the memory leak:

        public event EventHandler<MyEventArgs> MyEvent = delegate { };
 
        private void CreateNewViewButton_OnClick(object sender, RoutedEventArgs e)
        {
            CleanUpPreviousView();
 
            var newView = new MyView();
            MyEvent += newView.EventHandler;
 
            ViewContainer.Children.Add(newView);
        }
 
        private void CleanUpPreviousView()
        {
            if (ViewContainer.Children.Count > 0)
            {
                var myView = ViewContainer.Children[0] as MyView;
                if (myView != null) MyEvent -= myView.EventHandler;
                ViewContainer.Children.Clear();
            }
        }

Let's see if this really fixed the memory leak. If we fire up the application and press the button a couple of times, the application should normally only have one live reference of MyView in memory.

I clicked the button 5 times, and the above output shows that there are 5 instances of MyView on the heap. So did we fix the leak or not? Check the output below:

As you can see, only the last instance of MyView is actively referenced somewhere. That means that the first 4 instances are ready to be collected during the next garbage collection.

One thing i don't understand though, is that the reference chain of the last instance doesn't mention MainPage or the event handler anymore. But when i attached Visual Studio's debugger to the browser instance i could clearly see that the MyEvent of MainPage indeed contained an event handler that pointed to this MyView instance. I'm far from a WinDbg and SOS expert so i have no idea why the reference chain doesn't reflect this. Perhaps someone with more WinDbg and SOS knowledge can shed some light on this?

Either way, this approach is a pretty good way of finding memory leaks in your Silverlight code. In a real application it's obviously a bit more complicated to find the exact cause of a leak compared to this simple example, but it's still pretty doable. Just execute the !dumpheap -stat -type YourRootNameSpaceHere and look for unusually high numbers of instances of your types. Then you can start looking at each instance to figure out what's going on. And for a nice list of commands that you can execute in WinDbg with SOS, be sure to check this out.

Also, keep in mind that you can do this for every .NET process, and not just Silverlight. Though you would need to load the sos.dll file of your particular .NET version.

We already have a base PresentationModel which has the following method:

We also have a generic PresentationModel class which inherits from this class:

Notice that you pass an expression to the NotifyPropertyChanged method. It can be used like this:

That's pretty cool, but you should be able to test this easily, right? That's pretty easy to do as well:

There we go... no more strings so refactoring won't break anything, and it's easy to test as well.

In the past i have resorted to grabbing a memory dump of the browser and analyzing the content of the managed heap with windbg to track down which instances where being kept in memory. While this works, it's pretty time consuming and can quite easily lead you down the wrong path. One of the most important things that you want to know in this specific case is: which types are being kept in memory, and how many of them?

In this case, being able to query something during debugging regarding which instances are still kept alive in memory at certain times is sufficient for me. So i came up with the following class:

The idea is basically to just keep a list of WeakReferences of objects you want to track (only if a debugger is attached), and later on you can 'query' the live instances through the GetAllLiveTrackedObjects method. This method obviously performs a full garbage collect to make sure only objects that are really still alive are returned. Again, you should almost never do a GC.Collect() manually, but in this case the method will only be called while you're debugging.

Then, you strategically put the following line in the constructor of every kind of type you'd like to track:

I have that line in the constructor of my base View class, my base Controller class and in my base Disposable class. So now, when i want to check if there are any dangling references to instances of types that i really don't want hanging around, i can just do something like this:

And then manually inspect the content of the liveObjects collection. It's far from perfect, but at least it's an easy way to at least know which instances (that i care about) are being kept in memory. It'll do until we get better tool support :p

The general idea is to be able to implement each client application in its own Silverlight Application Project, and to have the ability to download each client aplication's XAP file into the Host application and display it within the designated visual area for the currently active client application.

First, we need an interface that each client application needs to contain an implementation of:

The VisualContainer property needs to return a UIElement which is basically the main visual container element of the client application. This could be its main page or just a grid or just about any graphical component.

Then we need a class to download XAP files based on their URI. Since you have to do all of these things asynchronously in Silverlight, and the generally used approach seems to be the event-based async pattern, i use the following base eventargs class for all of my asynchronous operations:

And then we have the DownloadCompletedEventArgs class:

Now we can write our simple FileDownloader class:

We also need something to extract the assemblies from a downloaded XAP file:

And then we can write a class which can retrieve the type which implements the IClientApplication interface from a downloaded XAP file:

Obviously, this code doesn't deal with the possibility of multiple or no IClientApplication implementations within the same XAP file. Not really relevant for this post though

And now, we can simply do something like this within our host application:

and the LoadCompleted event handler could look like this:

And that's all there is to it.

Update: download a sample of this here.

In the output folder of the Silverlight project, you can clearly see that the Our.KickAss.Silverlight.Project.resources.dll file is located in the 'nl' folder. The XAP file that is being copied to the actual web project however, doesn't contain the dutch resources.

Apparantly, the key to 'fixing' this is opening the .csproj file of your Silverlight project, and then you need to modify the SupportedCultures element so it contains the cultures you're supporting:

There might be a way to do this from the UI within Visual Studio, but i sure didn't find it anywhere.

And now you can simply switch between the translations setting the generated resource class's static Culture property to the culture you want, for instance:

The new out of browser experience in Silverlight 3 enables users to place their favorite Silverlight applications directly onto their PC and Mac, with links on the desktop and start menu—all without the need to download an additional runtime or browser plug-in.

So we can create .NET applications that run on the Mac now

Sure, they'll be sandboxed and you can't do everything a real native application could do, but this could still be a pretty compelling deployment choice.

So i started looking into the usual things: making sure disposable instances where disposed of properly, that evenhandlers were unregistered properly, etc. I went over the code and it seemed to be alright. Stepping through the code with a debugger verified that disposables were indeed disposed of, and that all event handlers were unregistered.

So why was pretty much everything kept in memory? Further research with windbg showed that every ProgressBar instance that was ever created (and we use a lot of them, basically every time we make a call to the application server) kept a reference to the UserControl it was placed on and thus, kept the UserControl and all the references it contained alive. In our case, that includes our presentation models and obviously all of the contained child UserControls.

The ProgressBar is defined like this:

<ProgressBar Height="40" Style="{StaticResource ourKickAssStyle}" VerticalAlignment="Center" Width="40" IsIndeterminate="True"/>

The key here is the usage of the IsIndeterminate property... setting this to true causes the ProgressBar to move continuously without respecting any current Value property. You know, basic stuff. The thing is... if i change the definition of the ProgressBar to this:

<ProgressBar Height="40" Style="{StaticResource ourKickAssStyle}" VerticalAlignment="Center" Width="40" />

The memory leak suddenly went away

Obviously, this isn't a solution because the ProgressBar now doesn't really indicate any progress and we need our kick ass custom animation to retain the coolness of the application.

So for some reason, when you set the ProgressBar's IsIndeterminate property to true, it actually keeps all of its references alive even when the ProgressBar control is removed from its parent control. Happy times.

We now have the following ugly method in one of our base UI classes:

        private static void StopProgressBars(DependencyObject dependencyObject)
        {
            var count = VisualTreeHelper.GetChildrenCount(dependencyObject);
 
            for (int i = 0; i < count; i++)
            {
                var child = VisualTreeHelper.GetChild(dependencyObject, i);
                if (child != null)
                {
                    var progressBar = child as ProgressBar;
 
                    if (progressBar != null)
                    {
                        progressBar.IsIndeterminate = false;
                    }
 
                    StopProgressBars(child);
                }
            }
        }

But it appears that the people who feel this way about Silverlight's future are in the minority. You don't see a lot of the really big name .NET bloggers talking about Silverlight (although there are a few), though i'm hoping that will change over time. In the meantime, i'd like to know what you think Silverlight's future will look like. I've put up a new poll with the following possible answers:

• It's never going to take off in a meaningful way
• It might pick up some steam for media-related purposes, but that's about it
• It will pick up more adopters as the platform matures and offers more out-of-the-box capabilities for typical business applications
• It's too different from traditional web development to appeal to most web developers
• It will reach wide adoption, but never more than that of typical web apps
• Someday it will be the default development platform for .NET web developers

(NOTE: for those of you reading this through the RSS feed, the poll is only accessible on my site and is located at the top right corner of the page)

There will obviously be some missing options, so feel free to point them out in the comments. I'm looking forward to the results and your thoughts on this topic