I imagine that most developers when presented with the concept of Silverlight have a very joyous first response. And then the next thought is a pragmatic one of wondering how much code (source or binaries) can be shared between Orcas and Silverlight. In the past, I've come across some pretty interesting uses of ASP.NET to share experiences across both the server and the offline client. Today, I'm pretty sure that we can offer a better scenario than that.

Before we go into details, let's talk scenarios. My dream scenario is that TurboTax would move their web-based version to Silverlight, and their client version to full WPF. For the Silverlight version, I'm thinking of a pretty immersive application, along the lines of the nibbles tutorial or the new Tafiti search app. I can easily see a major improvement in customer experience, including for me, a multi-year TurboTax customer.

The question on the table is the degree to which Turbotax developers (for my dream scenario) could share code across those two presentations of Silverlight. There are two parts of that: the UI layer (WPF code, xaml and other assets), and then the business logic. Although possibly the most interesting topic, I won't address the UI at this point since the WPF and Jolt teams are still working out the kinks on that issue. The business logic aspect of the issue is well within the purview of what I've been working on.

Our goal for business logic has been pretty simple: subset the existing Orcas stack for the BCL, XML and other base technologies in a very, very compatible way. We want folks to be able to take their Silverlight business logic, and re-use it on the desktop. For Turbotax, you could imagine them being able to port all the code that calculates your taxes against the static IRS tax tables to Orcas. At this point, we're focussed on making source re-use work really well. Binary porting is definitely something that's on our list, but not what we consider to be the mainline scenario since you'll need to re-compile your UI code anyway. I'd like your feedback on it if you have a differing opinion.

You might notice that I'm talking about porting code from Silverlight *to* Orcas. The reverse direction isn't nearly as compelling. By definition, Silverlight will always be a subset of Orcas, and your Orcas code may have a lot of dependencies on types that are only part of Orcas. Starting from Silverlight, you know that all of the APIs that you use will also be on Orcas, and you're experience porting to Orcas will be straightforward.

One kink is that we've added APIs to Silverlight that are not in Orcas. So, my story as described above is actually a little flawed. Naturally, we'll add those to the next desktop release after Orcas, but there is a question of how to deal with that in the meantime. We do have a solution for that that we're working on. I'll post on that when I have firm details available.

Judging by the search engine traffic to my blog, it appears like folks are still looking for gacutil!

I wrote this post almost 2 years ago, relating to Whidbey, and the location of gacutil at that time.

Gacutil, and the rest of the SDK, has moved again. You can install it with VS 2008 or separately. In either case, once installed, you'll find it on your disk @ C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\gacutil.exe.

BTW: The .NET Framework SDK now has a new name, so searching for the .NET Framework SDK doesn't work as well now. It is now called "Microsoft® Windows® Software Development Kit (SDK) for Windows Server® 2008 and .NET Framework 3.5".

I've been using Terminal Services (AKA 'Remote Desktop') since I started working at Microsoft in 2000. Back then, we were using Windows 2000, natually. After having used the 9x family of Windows since Win 3.1 (and DOS before that), the whole concept of 'TS' seemed pretty incredible. Yes, I'd used similar facilities on other OSes, such as Solaris, but never on Windows.

Windows Server 2008 brings along with it another similar and related breakthrough. It's called RemoteApp. Instead of remoting a whole desktop, it remotes an application. The initial logon process is very similar to Remote Desktop, but after that, you really do have a window that operates just like any other window on your desktop. There are some aspects of 'remote-ness' that leak through, but they are far, far, overpowered by the utility of the feature. Also, you don't need to logon for each window, just once for the machine from which the RemoteApps are remoted.

I've been dogfooding this feature for a while, and I find it incredibly useful and productive when working from home (which I do a fair bit -- like right now). Imagine having a RemoteApp IE window on your desktop that is on your corporate network. You have your regular IE on your desktop that you use to view random web content, and the RemoteApp IE that you use to browse your corporate network. This is super useful for sharepoint sites on your corporate network.

Next step is to convince (A) your CFO to buy a bunch of Windows Server 2008 boxen, and (B) get your admins to turn on this feature.

The comments on yesterday's post on compatibility are pretty interesting.

There are effectively four options available when you find yourself a few versions into a platform and realize that you've made mistakes:

1. Keep the mistakes, and potentially propogate those mistakes into other parts of the platform
2. Rip out the mistakes, re-design the feature (sans mistakes) and accept the breaking change and broken apps
3. Re-design the feature without the mistakes, add that re-designed feature to the product, deprecate the old broken feature, and accept duplication for some period of time until the older feature is ripped from the product
4. Re-design the feature, add some elaborate compatibility mechanism to emulate the old behaviour, and sign up to maintain the elaborate compatibility mechanism for a long time

There may be some other options, but these are the ones that come to mind.

The comments from yesterday were in favour of (2).

I'm in favour of (3) as the primary model for making the product better, with a little bit of (2). I'm also willing to accept some of (1). I really dislike (4), as it doesn't benefit anyone in the long-term. (3) works well for individual APIs, but doesn't work well for whole sub-systems, such as the loader. If you change the loader in an incompatible way, you're really looking at options (2) or (4).

We've actually made a bunch of changes in Silverlight to improve the platform. As examples, we've removed non-generic collections, and have changed the way String comparisons work. We also changed the binder pretty significantly. Not to mention a new security system ... Oh, and we also included a stripped down XMLReader/Writer!

Compatibility is a tough balance relative to product evolution. We've been discussing this exact issue a lot over the last year, and the best way to evolve the project forward. The trick is coming up with a model that you really life, doesn't hugely impact the engineering process, doesn't inhibit product evolution going forward, and is explainable to customers. Taking submissions now ...

I was just reading an Old New Thing blog entry about compatibility. I get the point that Raymond is making about compatibility. It reminds me of a lot of conversations that we have in building 42.

I talk to folks with the same proposal of pulling out the 'compat crap' to make the product better. I have two thoughts on that:

• We'll be having this same conversation one release from now when we've implemented and shipped another set of designs that you don't like, when looked at in hind-sight
• There are a ton of folks that have invested a ton of time and their livelihood into the apps that they've bet on our platform. What do you want me to tell them?

Compatibility is feature number 1. Without it, you don't have a product, at least for very long.

I noticed that my last posts were about Vista 2005 SP1 on Vista. I had a bunch of trouble with that experience. I'm sure that the rough edges were polished out later on, but my initial experience could have been better.

I've been running Visual Studio 2008 (AKA 'Orcas') B1 and now B2 on Vista SP1 builds to write Silverlight v1.1 apps. I've got to say that the experience has been great. A bunch of work has been done to support UAC (the fundamental issue) by the VS and .NET Framework teams, and this on its own will be worth a big part of the price of admission.

I've also been building/debugging DasBlog (the blog software used to run this site) in VS 2008 B2 on Vista SP1 with IIS7. IIS7 is a pretty big change. After a few tweaks, help from the ASP.NET/IIS team and a bunch of help from the DasBlog team, I got it working. See Scott's post and post for more info.

There was only one problem in VS 2008 B2 w/IIS7 integration. That issue will be fixed in the next public release.

All in all, it's great to see a quality product, one that I'll be using a lot, coming from the VS team.

I've been working on various aspects of Silverlight since sometime last year. The project has been going on much longer than that. It took a while for the managed API to come online and then even longer for good tools support, and all of this is before the product was announced. And all that time, you'd think that folks close to the product were generating a ton of samples and cool apps. Well, not really. There were some, but most folks (including me) were just cranking on getting the thing ready for Mix and then the refresh/RC that followed.

So, I'm now happily playing with the product. I'm in the middle of creating a photo gallery website for myself to replace the lame DHTML site that I wrote back in 2003 on ASP.NET v1.1.

I'm left with some random thoughts on the product and how it affects and empowers developers:

• Compatibility between the server, the web-client (Silverlight) and the client (WPF/Winforms) is incredibly important
  • At the very least, developers benefit from knowledge transfer across the platform
  • Compatibility makes life easier for developers
  • More importantly, it opens up a ton of interesting scenarios between the different parts of the platform
• A highly flexible and easy to target ActiveX control is liberating
  • I've written a bunch of javascript to improve user experience in the browser. I'd be happy to never do that again, given that the development experience is pretty bad.
  • You can create amazing visuals and immersize experiences that would never be possible with Javascript.
• Silverlight also opens up a lot of questions for its use in the browser
  • Do you use Silverlight for your entire site, or only the parts that make sense?
  • What do you about navigation, particularly as it relates to forward and back buttons?
  • What do you do about folks that what a URL for a specific part of your site to send around, or return to later (bookmark)?
  • Flash has been around for a while, and has all of these same problems. Some sites use Flash for ads, others for widgets and still others that do the whole site thing. I've always disliked the whole site thing as a user.
• Silverlight has an opportunity to hugely improve on the current Web experience
  • Most importantly, we've just let lose all those managed developers out on that ;)
  • This is the start of real internet applications, and of much more interesting web sites. Cannot wait to see what Amazon chooses to do.
  • This opens up a new x-browser (and OS) application platform to developers
  • Flash isn't always the best experience. It does crash and you sometimes get this dialog about 'waiting for a long-running script'.
• Is this yet another Microsoft technology that developers have to learn?
  • Yes and no. If you know WPF already, then you'll be at home.
  • If you don't know the .NET Framework, then Silverlight is a great way to learn an impressive set of basics.
  • There are some differences to learn, but it's all minor
• Is Microsoft serious about x-brower and x-OS?
  • Yes.
• Are .NET Framework teams stoked about Silverlight?
  • Last time I checked ;)

As I work more on my photo gallery site, I'm pretty sure I'll develop more thoughts and hopefully some answers to some of the questions that I've raised.