Believe it or not, Microsoft’s 
Windows Live Writer is important in more ways than one. To most PC users, Windows Live Writer is simply the best tool that gets the “job” done. More importantly is how “job” is defined though, because WLW does things quite well and quite thorough.
Windows Live Writer has a huge range of options and takes advantage of almost all the features and functionality available via remote blogging/XMLRPC that make it almost pointless to even enter your blog’s administration center. You can upload images and movies, set categories and keywords, specify the slug/permalink to posts, modify the post date, set passwords on posts, send trackbacks, manually create an excerpt, and even specify whether comments are or aren’t allowed on any given post – all this without leaving your desktop client.
But what most don’t know about Windows Live Writer is more what it represents than what it does: Windows Live Writer is the first full-scale consumer product to ship out of Microsoft’s camp built on the .NET Framework.
Ever since the release of the Microsoft .NET 1.0 Framework back in January 2002, one of the biggest questions asked by .NET-skeptics has been why Microsoft doesn’t use the .NET Framework for its own desktop products and services – especially when companies like Sun take every opportunity to use their own frameworks in the all their products and applications.
And, truth be told, that’s a pretty tough question to answer. On one hand, you have Microsoft selling the .NET Framework as the next stage in software development, complete with the RAD framework that is .NET backed by powerful languages of the likes of C# – perfect ingredients to make highly-productive code that does what you need it do in easy time and damn decent performance.
But at the same time, you have the huge range and sheer number of products shipping out of Microsoft’s camp that aren’t feeling the .NET-love. From Microsoft’s Office Suite to their assortment of small programs and utilities, the question remained: if C# + the .NET Framework are such a great innovation/revolution/foundation, why weren’t they being used to develop Microsoft’s own software?
We’re not in a position to know beyond the shadow of the doubt what Microsoft’s line of reasoning on this subject was, but there are several likely answers. For one, there’s the fact that a large percentage of Microsoft’s bigger offerings pre-date the .NET Framework – and backwards compatibility, one of Microsoft’s biggest focal points, is easier to maintain with the existing codebase. And, of course, the cost and effort of porting a complex system or suite from one language (C/C++) to another (C# + the .NET Framework) is nothing short of a Herculean task.
But Windows Live Writer is a fresh start, and it seems the Windows Live team has chosen to use the .NET Framework as their tool of choice. Perhaps it was a trial run: use the .NET Framework for a non-enterprise/non-business application and see how well it fairs with regards to performance, reliability, and maintenance. If so, then perhaps this is the straw that will break the proverbial camel’s back – and an indication of more .NET-powered programs to come?
There is nothing more important than having the people behind the .NET Framework using the .NET Framework – and it’s especially ironic since it was Microsoft that made “eating one’s own dog food” popular in the first place (as a concept, if not a reality). There is no need to point out the benefits that this would bring, and, more importantly, the stuff developers would not have to deal with any more.
Back when Microsoft was still making Longhorn, one of things that had developers so excited was the expected prevalence of the .NET Framework throughout the entire operating system. That would have meant the death of COM and DLL hell thanks to the .NET GAC and much nicer interfacing/import options available. And sure enough, that was one of the biggest disappoints in the series of what Vista turned out not to be.
If WLW is any indication, this could be the start of a new era for .NET developers around the globe. Windows Live Writer has come off to quite a promising start, and hopefully the people in charge realize the benefits such a shift in policy could bring.
I agree, WLW is a great tool, and I’m glad to see Microsoft begin to use .NET in more of its products. However, WLW isn’t the first major .NET product Microsoft has shipped. Windows XP Media Center was.
See here at Coding Horror.
Well, it’s been an interesting day of research! Thanks for that info on the Windows XP Media Center shell being the first .NET app, I had no idea and took a lot of digging to find the hard facts (MSDN documentation on writing plugins for the MC).
IMHO one of the reasons MC-development didn’t take off is because it was using the 1.0 Framework – both because 1.0 was a real PITA with many respects and because when MC was released everyone was already using v1.1 without any focus or real prospect on backwards compatibility (unlike the current situation with 2.0-3.5 all being fully supported in Visual Studio 2008).
Anyway, thanks for the correction 🙂
Thanks for the kind words about Writer!
FYI, the new Zune software uses .NET (not sure exactly what version is required though). And I believe the vast majority of our webapps use ASP.NET.
Yes but what microsoft does in-house is not as important as what it ships out, i think you will agree.
Joe, how was working with the .net framework for writing Windows Live Writer (i am assuming you were one of the developers, no?)? Any new .net projects planned?
(i hope it is not inappropriate to take this opportunity to thank you for this wonderful program, i love to use WLW! keep up the good work.)
greetings from paris.
You’re most welcome Joe, just giving credit where credit is deserved – congratulations on a product well done. 🙂
I haven’t checked out the Zune program yet myself, but I’ve heard nothing but praise for it from a technical point-of-view — I guess Microsoft really is going full-force with .NET-based development now!
If WLW is exclusively using the .NET framework, why won’t they let the installer run on Windows Server 2003 or 64-bit versions of Windows?
We were actually going to post about that as well – the installer for some silly reason won’t run on Server 2003 or even 2008, nor on XP x64 (but it does on Vista x64 even if the installer claims otherwise).
Solution is to run the installer on a compatible PC, let it extract the MSI to your temp folder, then run the MSI on any .NET-based computer of your liking – it’ll install just fine then.
Running it as I write this from Windows Server 2008 Nov. CTP.
It’s plugin model is also good and useful. Maybe the IE team should learn from their plugin model and go the Firefox way.
Elly, choosing .NET has been a big win for us overall. It definitely enables us to be very nimble and crank out features at an uncommon rate. The times we have to drop down into C++ are pretty painful in comparison, especially for UI work. There’s no question in my mind that we would’ve needed either a much bigger team, a lot more time, or a lot fewer features if we had built Writer in C++.
Steve–there weren’t enough testing resources to certify whether all the Windows Live apps ran well under Server 2003 or XP x64. We do run under Vista x64 (the previous beta did not, but that was just because of a plain old bug in the installer which was fixed before final).
I believe that the Vista Sidebar is also completely written in .NET.
Isn’t MOSS powered by ASP.NET?
Joe, thank you for sharing that with us. It is very inspiring to hear that.
I feel the same way about C# and Microsoft .NET too – it is so much faster and easier to write good code with C# than with C++.
One can argue that Microsoft didn’t have much of a choice with MOSS – it was either ASP or ASP.NET – and no one buys an ASP (non-.NET) version of anything these days…
To the best of my knowledge, some parts of tools and utilities that ship with Windows Vista are written in .NET, but I personally wouldn’t count them as .NET packages shipping out of MS simply because they’re not independent programs.
Chris, if what you say is true, then here is the million dollar question: If the sidebar is written in .NET, and .NET makes it real easy to extend programs and functionality via interfacing, then why are we forced to use pitiful “programming languages” like JavaScript to write the widgets? Imagine how much better the sidebar could be (and how much higher the signal:noise ratio would be!) if widgets were written in C# and not JS!
At any rate, thanks for this write-up — it certainly is interesting to see a refreshing look on the path .NET is taking, and especially when it comes to the Microsoft side of things.
(PS: Let me second CG’s opinion here – great work on WLW, Joe & the rest of the team!)
Well, while I agree with you that C# is a thousand-and-one times more flexible and powerful than JS, it’s occured to me that perhaps that is the reason Microsoft chose to have developers writing sidebar widgets in JavaScript in the first place.
Basically – it’s real easy to screw a system over with a single line of bad (accidental or otherwise) code in C#, but in JavaScript it’s virtually impossible – that’s what makes Firefox extensions so safe compared to ActiveX components.
JavaScript is limited to its container (the sidebar) unlike C# which could be used to do a lot more. While it would give developers infinite potential, perhaps it was a security burden that Microsoft did not want to shoulder? (I can imagine the Slashdot headlines already 😉
I do agree that it would be nicer and we could do alot more with Sidebar Gadgets if we could write them in C#. However, I believe they chose to use JavaScript so that they could use IE as the host within the sidebar so there aren’t any security issue, and so they wouldn’t have to write a completely new scripting engine just for the sidebar. This reminds me, why doesn’t MS have a Live Messenger gadget that makes messenger live in the sidebar instead of the SysTray, but then again maybe it’s because they didn’t us the power of .NET to make gadgets.
I know that it should be able to be done.
perhaps microsoft needs to first release a activex component for msn messenger, but i thought there already was one. Then a javascript script running in the ie host in the sidebar can communicate with the activex and display whatever you need it to.
Perhaps it can already be done, but it needs a creative developer to sit down and do it?
That’s actually quite an interesting subject you bring up, Elly.
What you’re suggesting seems more than possible, and it does look like all the tools you’d need are there even.
From Daniel Moth’s page:
Writing gadgets that use ActiveX controls: http://blogs.msdn.com/sidebar/archive/2006/09/28/775835.aspx
WPF Gadgets: http://blogs.msdn.com/karstenj/archive/2006/10/09/activex-wpf-gadget.aspx
The latter isn’t a viable option though.
Working with ActiveX and Windows/MSN Messenger: http://msdn2.microsoft.com/en-us/library/aa164953(office.10).aspx
It’s certainly not a trivial task, but it can theoretically be done.
It wouldn’t be any managed code though (unless you wanted it for proof-of-concept, because it adds a hell of a lot more work rather than relieving you of it).
But like you said, Chris, this is something that the Windows Live Messenger team would be in the best position to release 🙂
First consumer product? No.
Media Center was the first consumer product to be written in .NET – since it shipped in 2003. You can argue that it’s a part of Windows, but it is most certainly a product.
The new Zune software is based on Media Center, and it’s also .NET.
Expression Blend is also based on .NET (and WPF), but I’m not sure if you can call it “consumer”.
Heck, I saw a .NET application at the dentist today, and I’m working on one professionally (ASP.net) right now.
You have to understand – .NET 1.0 sucked, and 1.1 was still pretty incomplete. It wasn’t until .NET 2.0 came out in 2005 that I believe the framework became ready for prime-time.
I know what you mean about 1.0 and 1.1, that’s the reason .NET never took off until ’05.
Just for the record: Windows Live Writer builds were released before the new Zune software (tried it, it’s pretty awesome!); but that’s a moot point seeing as the MCE shell is .NET as was pointed out in your comment and other’s.
Expression Blend is like Visual Studio: it relies heavily on those technologies, but it’s not written in them.