I was reading Tim’s post over here on “Silverlight 4 with COM can do anything – on Windows” which referenced Justin’s amazingly detailed post with a bunch of COM interop examples from Silverlight 4.

A Silverlight 4 beta application that has been explicitly installed as trusted by the user can create COM objects if they have a registered ProgId and if they implement IDispatch.

As anyone who’s been around Windows for a while and especially anyone who wrote scripting code like ASP pages will know, that opens up quite a lot of code to those applications. I think that was made pretty clear at the PDC when the feature was first announced.

My personal view is that the COM interop feature is something that you'd use sparingly to add additional functionality that becomes available when and where COM interop is turned on rather than writing a tonne of code that takes the COM interop route.

Why’s that?

Firstly, you might find your application goes into an environment where the users aren't allowed to run trusted Silverlight applications at all. It's driven by group policy and the admin may well make a decision that the policy will not allow the installation of your trusted application.

Secondly, going down the COM interop route makes your application Windows only. I disagree with Tim’s previous post in that I think that there are many good reasons to build a Windows-only application today and I agree with what Marc wrote here on that and have some other views of my own that I’ll add in some other post.

However, Silverlight is a cross-platform framework so if you need a lot of Windows-only functionality then you might look to a Windows-only framework like WPF which will get you that Windows-only functionality without forcing you to leave .NET and drop into…

Thirdly, you leave your .NET world of metadata-driven strong typing and IntelliSense and drop into the [best/worst – depends on your viewpoint] part of the COM world – IDispatch programming which was never (imo) a pleasant place to be. Debugging across that boundary isn’t really that pleasant either.

Fourthly, there's no way of deploying or versioning the COM code that you're taking a dependency upon and no pre-installation step where you can check those COM pre-requisites. That might be as something like trying to know whether the right COM components from Microsoft Office are installed or maybe making sure that some installed components are 32-bit rather than 64-bit and so on.

So, I think Justin's post does a very good job of illustrating some of what "interop via IDispatch" can mean in terms of being able to call lots of existing Windows code.

However, that doesn't necessarily mean that building an application where you write reams-and-reams of COM code in Silverlight is a good idea. Not that I’m suggesting that Justin was saying that in the first place by the way.

In my opinion, for those kinds of scenarios you'd save yourself a lot of blood,sweat and tears by writing a .NET 4.0 application with WPF and the whole of the .NET Framework at your disposal.

Now, it might be that you’d say “Ah, but I’d then have to deploy the full .NET Framework”. Maybe. If you’re targeting Windows 7 or Windows Vista (3+ years old now) or then the .NET Framework with WPF is already installed and ScottH recently posted figures pointing to;

• Well over 90% of the PCs in the world have some version of the .NET Framework installed.
• Over 65% of Windows PCs in the world have .NET 3.5 SP1 installed.

so, that’s a pretty healthy 65% on the latest version of WPF and might alleviate your worry about getting the .NET Framework out there. There’s also smarter deployment options for the client part of the Framework with the .NET Client Profile ( especially in .NET 4.0 ).

So, my view – I like Silverlight. It’s fantastic for building rich internet applications. I like WPF too. It’s fantastic for building rich Windows applications. Choose the one that best suits your purpose.