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.

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'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.

I've been running an early adopter program for a couple months now for a bunch of changes that we're making to the CLR binder/loader in the CLR v3 timeframe. The changes are related to the binding model, versioning, servicing and an add-in model. Also, just to be clear, this isn't .NET Framework v3.0 (AKA WinFX). This is the one after that. Here is the blurb that I sent folks who I thought might be interested. Please @ mail me if you are interested in participating.

We have been busy designing some exciting new changes to the CLR loader/binder. We'd like to start collecting feedback from customers about our change early, in order to ensure that the final product is rock solid. The first phase of the program is to validate that our changes are useful and to understand the compatibility of these changes. In order to collect this information, we’d like you to run two tools on your system so that we can learn more about how you – actually the managed apps you use – use the loader and GAC. The one tool is a tool that collects very basic information about the GAC, while the second tool is actually an instrumented CLR which logs data about how the loader, binder and domains are used. The next phases involve running a prototype version of the CLR that includes the new changes, but we’ll get to that later, as it comes available.

There are also a couple legal documents to sign, specifically an MSFT NDA and a license. I'm happy to discuss those if you want to go to that stage.

I'll be attending the Visual Studio 2005 launches in both Vancouver and Calgary next week.

I'm definitely looking forward to both. I'm up to Vancouver all the time, being only about 2 hours to the Canadian border from Redmond, plus parts of my family lives in Cloverdale. I'm very curious what the Vancouver .Net crowd is like. I have to admit that the Toronto crowd blew me away, with a turnout of >3000 developers and IT professionals. I guess I should admit that a bunch of those might just have happened to be there for SQL Server 2005 or Biztalk 2006. That being said, it did seem like the VS 2005/.NET Framework "experts" in the "Ask the Experts" area were particularly busy.

I haven't been to Calgary since ~2001. My best friend lives there, so we'll likely hit the slopes (Rockie mountains) if the weather co-operates.

Please introduce yourself at the launches if you are able to make it. I'll be in the experts area most of the time. Also, please mail me if you'd like to setup some time to meet, either at the launch or elsewhere, to discuss development issues. I had good luck meeting with banks in Toronto and would like to have similar meetings in the West. I guess I should ring up the oil patch while in Calgary and see how they're using .Net.

Us "experts" typically have dinner together directly after the launch. Please mail me if you'd like to join us. This is a good chance to spend 90mins with the likes of John and Jerome. John refers to himself as a plumber.

Yes. Please send mail to netfxcmp@microsoft.com to get signed up for this free program.

We're trying to do the right thing and get as many apps/controls/add-ins as possible to ensure that Whidbey is a compatible release. We have a bunch of apps already in our lab and have tested them extensively looking for any compatibility issues. We use these applications to establish a baseline of behavior and we’d like to add your app to the mix to ensure we haven’t missed anything. If we add your application to our appcompat tests, we are not just going to use them for testing compatibility with .NetFX 2.0, but we’ll add them to our regression suites and test them against the SP’s and future FX releases as well.

Take a read at this eWeek article, just published today. The article is a little dire in spots (including the title), but the basic idea is that we have a compatibility program and are ramping it up before we ship, now that the product is stabalizing in preparation for shipping. Most apps do "just work".

This blog, a dasBlog blog, is an example of "just works" on Whidbey. The dasBlog blog engine is an Everett ASP.Net web app, written for the 32-bit Everett (v1.1) CLR. My instance of dasBlog is running on top of the 64-bit Whidbey (v2.0) Beta 2 CLR. It "just works", as you can see.

Please do send in your app to add it to our mix of apps tested in our compat lab. You can also do compatibility testing yourself. See the Compatibility Testing Scenarios doc on MSDN for detailed instructions on how to do your own compatibility testing.

Here is a blog entry from JasonZ, our Product Unit Manager, on your compat and project upgrade experience. And an MSDN article on Whidbey compatibility. I encourage you to read these articles.

Caveat: This "free program" isn't long-term. We need a bunch more apps in the short term to beef up the sample size of apps in our compat lab. At the point we believe we have enough apps in our lab, we'll no longer need this program.

I watch the traffic that goes through my blog. Dasblog, the blogging software, lists the search terms and the search engine of the hits that come through a search engine. As an aside, 100% (at least lately) of the searches come from google.

One of the searches from today was exactly the title of this post -- can you use a library compiled against v1.1 in v2.0 of .net. The answer is absolutely "yes" and migrating to Whidbey (either v1.x source or binaries) is a completely supported and encouraged activity. If you have any (I mean "any") problems with your migration process, please drop me a line @ rlander@microsoft.com. I know all the right people to talk to and can get you an answer back quickly.

Here is the search URL for that query (yes, it came from google UK):

http://www.google.co.uk/search?hl=en&q=can+you+use+a+library+compiled+against+v1.1+in+v2.0+of+.net&btnG=Google+Search&meta=

I'm a little short on time at the moment. In a later post, hopefully tomorrow, I'll explain how to move your app to Whidbey from a CLR binding standpoint. This is an easy process and takes only a couple minutes. You may want to do this for testing or to port your app to Whidbey now that we have a "go live" license for Beta 2. See this earlier post for more info.

I will state up front that there are known issues with asp.net source migration. The goal for Whidbey (v2.0) RTM is that the use of the migration wizard plus manual tweaking for a significant site should be on the order of hours (as opposed to days or weeks). We're thinking around a morning or an afternoon.  Binary migration (for all v1.x code -- not just asp.net) should "just work". As I said earlier, please mail me if your mileage varies.

I have heard this question before. Hopefully this post helps get the answer out there in a more broad manner.

Claudio, Mike and I had a great week in Phoenix. We definitely noticed the change in temperature from what we're used to in Redmond. The hottest day was about 40C/104F. And this is referred to as "cool" by the weather man here! Hate to experience "hot", which apparently starts at around 115F and heads up to 125F. Ouch! If I was here then, I'd end up in the hospital. Although, now that we're heading back to Redmond, we'll miss the warmth of the Arizona climate since we're likely headed to much cooler temperatures and a bit of a tropical storm. From talking to Annie, my wife, during our trip, I've been hearing about all of the rain that we've been missing.

I'd like to thank Tim Heuer, the Developer Evangelist for the SouthWest region, for organizing our trip. He worked for a number of weeks before we arrived with a number of customers to develop a jam-packed schedule for us. We met with 2-3 customers per day and then had dinners at night with Microsoft partners and the local .NET user group. This resulted in 13 hour days on average. Must sleep now.

We took the time out to travel to Phoenix with three goals: (a) get feedback from our customers on their use (i.e. challenges and wins) of the .NET Framework, (b) provide customers with access to CLR experts to address their questions, and (c) ask customers for their apps and/or unit tests for use in our compatibility lab (more on this later).

We left Phoenix feeling quite happy with achieving our goals. We took a lot of notes and are going to use those in our planning for the next version of the .NET Framework (v3.0). We are almost done working on Whidbey (v2.0) and are starting to move the Program Management team (i.e. Claudio, Mike and me) to writing high-level specs on v3 features. For example, I'm doing a lot of work on managed code versioning. In terms of providing customers with access to CLR experts, I was very stoked about getting Scott Guthrie to meet with one lucky customer. This only worked out due to Scott being in town for just over 24 hours to speak at the Beta Days conference (where I am now) on Thursday. Scott didn't even break a sweat explaining how to best use certain aspects of ASP.Net. The customer quesions varried quite a bit but were more focussed on the use of viewstate. He also spent some time describing the new features in ASP.Net v2. One of the developers had this look in his eyes like he wasn't planning to go to bed that night, but migrating his company's website to v2 in order to get access to the new features!

Many customers were very excited about Visual Studio 2005 Team System. Claudio did an awesome demo of the CLR profiler built into the team system. I hadn't seen that before either and was quite impressed too. I can see using the profiler on the ASP.Net site that I'm currently building. I'm sure that I'm using much more memory than I need to be. There are many other new features in VSTS that customers are dying to start using, including load testing, code defect tracking, source control (not VSS), and FXCop. If you are in the South-West area, please contact Tim Heuer if you'd like a demo of VS 2005 (or any other developer technology).

I'd like to take a moment to address compatability. You've probably seen that as a recurring theme in my blog entries -- and this blog is supposed to be about the CLR loader ;). We made an offer to all of the customers that we met that I'd like to offer more generally. I haven't asked if this is OK to offer to the whole Web, but I'll do it anyway ;). We are very serious about backwards compatibility. We have a compatibility lab on the CLR team, in which we test v1.x apps on the v2.0 .NET Framework. Just to be super clear, we are testing the binary backwards compatibility of Whidbey. If an app fails to work/behave as expected, we determine why and then fix the problem in the v2.0 .NET Framework before it ships. We need more applications in the compatibility lab in order to have a better sample size of apps relative to the universe of managed apps out there in the wild. Ideally, we would have more apps that we can test and that they were very varried in terms of: internal business apps versus boxed apps, data components versus visual controls, ASP.Net versus Windows Forms, Windows Services versus Web Services, simple apps versus complex apps, database-oriented versus XML-oriented, natural language-specific (i.e. English) versus localized (i.e. Chinese, Hebrew, French), VB.Net versus Cobol, data-heavy (megs and megs of data in memory) versus CPU-bound. Hopefully you get the idea since I cannot think of any other axis of programs. Anyway, if you'd like to submit your apps or some part thereof, we'd love to talk. Unit tests are also great. We'll test the app until we ship Whidbey and then continue to ship it in the future to ensure that we don't break v1.x compatibility. In future, we'll look for v2.0 apps in addition to v1.x, ensuring that we don't break v2 compatibility on the v3 CLR.

Anyway, we had a great time in Phoenix. Turned out that our flight is delayed by 1 hour, but that's OK. This way we get to watch the sun go down in Phoenix. Quite fitting for the end of a great trip.

Just got home. It is is 1AM now. It is raining and 11C/51F. Just a minor change from Phoenix ;)   Definitely found out that flying -- landing in particular -- with a head-cold is not recommended. I still cannot hear anything, but fortunately my ears have stopped hurting. 

Some time ago, I moved my blog to a 64-bit X64 server. This server was running Windows Server 2003 SP1 Beta 1 and an early version of Whidbey Beta 2. I thought that this was an excellent opportunity to dogfood (MS term for early adoption) the 64-bit version of the framework, not to mention Server 2003 SP1. Another side aspect of this exercise was that I was testing out the backwards compatibility of the .NET Framework, since DasBlog is built with the v1.1 version of the Framework.

I'm happy to report that I've had zero problems with this new configuration, even with beta software. The OS has now shipped, so there is no issue there, but the version of Whidbey is still only Beta 2 and it is chugging day after day without issue. Doesn't get better than that! It also shows the incredible value of MSIL -- what C#, VB.Net, Eiffel, IronPython, Cobol and any other managed code compiler compiles down to -- given that the Everett DasBlog code "just works" on 64-bit Whidbey, even though 64-bit was not a supported (or possible) configuration of Everett.

One of the major features of Whidbey ASP.Net is XHTML compliance. DasBlog was not designed to be 100% XHTML compliant, so would not work on the first try on Whidbey. We had to use a special config switch to turn off XHTML compliance in Whidbey. After that, everything worked perfectly, in terms of performance, backwards compatibility and general behaviour of the app. I'm very happy and can say that Whidbey Beta 2 is ready for prime-time development. To that end, the .NET Framework is allowing companies to "go live" with our "go live" license. This means that you can build/migrate a public-facing application with Whidbey Beta 2.

Back to 64-bit ... I must say that the 64-bit support in Whidbey is very cool. I have two high-end X64 boxes in my office, one from Intel and the other from AMD. I use them for various purposes and am quite happy with them. In particular, I really like building and debugging apps on my 64-bit machines, having them run in native 64-bit, but then being able to deploy them to both 32- and 64-bit machines. The portability of managed code assemblies across different CPU architectures (IA64, X64, X86) is a huge win.

I've also been running early 64-bit versions of Longhorn on these two X64 machines. I haven't done any tests using >2GB of virtual address space, but I would like to see a managed app that does that, taking full advantage of the 64-bit address space. I can imagine that companies running SQL Server will immediately see the benefit of that removed barrier.

As you may guess/hope, we're doing our best to close down Whidbey Beta 2 ... so that we can ship it out to you to use. As part of that, we recently completed a security push to ensure that we are shipping a secure product. Another product axis that we also strive to deliver upon is compatibility. We have a set of processes and tools for ensuring that Whidbey is backwards compatible, to ensure that assemblies compiled against the v1.0 or v1.1 .NET Framework execute without issue on the v2.0 (Whidbey) .NET Framework.

You can help too, to ensure that we are delivering on compatibility in Whidbey. First, check out my colleague Jesse's posting @ GotDotNet that allows you to easily do compatibility testing against Whidbey Beta 1.

If you do find a problem, compatibility issue or otherwise, tell us about it @ the MSDN Product Feedback Center. We get this feedback delivered directly into our bug database and we deal with this feedback alongside the regular bugs that we get from our testing teams. Here is an example of a user-reported bug that we fixed that happened to be a compatibility-break.

I also plan to do a series on compatibility here to provide more transparent information on our compatibility bar and story.

One last thing ... here is our existing .NET Framework compatibility site. Jesse and I are planning on building a new site that is easier to use. I would have built it against Whidbey Beta 2, but he suggested that we build it against Everett/SQL 2000 and then host it on Whidbey/Yukon to dogfood Whidbey and Yukon compatibility. So, that's what we're doing. Cool, eh?