Our Product Unit Manager is hiring! Jason's post is about interns, but he has a link to regular jobs too at the end of the post. The CLR team is the best team that I've worked for at Microsoft. If you want proof, read this blog entry.

We are currently closing up Whidbey and doing some initial planning for Orcas. By the time you get here, we'll likely be prototyping ideas for Orcas. In fact, I have an executive review in just over a week with Jim Allchin on the managed code versioning work we are planning for Orcas. We'll see what he thinks. If you join the team, you'll find out ;)

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 need to post on the assembly version number for Whidbey again, for two reasons: (A) I never posted what it actually was, and (B) I posted some inaccurate data that I'd like to correct.

(A) is easy. The assembly version number for Beta 2 and RTM is: 2.0.0.0. This may seem to make sense for a version number, however for Everett it was 1.0.5000.0 -- not sure why that was chosen. 

(B) is slightly more complicated. I said in an earlier post that apps built on top of Whidbey Beta 1 (or earlier) would need to be recompiled. That is not true. They will work fine on Whidbey RTM without re-compilation. What will not work is Whidbey RTM apps running on the Whidbey beta 1 runtime -- which is presumably not a scenario for anyone.

(B) is true due to framework unification, which only applies to .NET Framework assemblies (i.e. System.Web.dll). The assembly binder basically does a quick test to determine if the version of a framework assembly is higher or lower than the one that ships with a given runtime -- meaning the runtime currently being run in the process. If it is higher, the load is rejected; if it is lower or equal, the referenced version number is ignored and the version that shipped with that runtime is loaded instead. We go through this algorithm to prevent Everett System.Web.dll running on Whidbey with Whidbey System.dll. Those configurations are not supported, so we prevent them from occuring.

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.

Managed Debugging Assistants are an existing feature (Customer Debug Probes) improved on and expanded. They are exposed in a similar manner to exceptions (don't let that scare you) but occur not because of an error condition, but because the runtime has noticed a condition that could cause you problems. We've talked to lots of customers over the years and have received feedback that there are a set of scenarios that cause developers pain more often than others. As a result, we've written a bunch of code -- the MDAs themselves -- that can be used while your code is running to protect you against these pain points ... that's good, right?

The MDA infrastructure is always "on", but only a few MDAs are activated by default. That's easily changed, by selecting the "Debug" menu and "Exceptions" within it. From there, you can turn on or off any MDA of your choosing, as you can see in the image below. There is only one MDA turned on in that part of list in the image below, but you turn on as many as you want.

Anyway, I want to introduce you to the LoadFromContext MDA. If you want to know more about the joys of LoadFrom, check out Suzanne's blog. I'll post more on binding contexts at some point, but want to stay on the subject of this MDA for the moment. Here is some code that exercises this MDA -- this is just an exe project attempting to load a built assembly from a class library project in the same solution (hence the strange pathing) ...

using System;
using System.Reflection;

namespace LoadFromMDA
{
class Program
{
static void Main(string[] args)
{
Assembly asm = Assembly.LoadFrom(@"..\..\..\SomeAssembly\bin\debug\SomeAssembly.dll");
Console.WriteLine(asm.FullName);
}
}
}

If the MDA is enabled, I get the following exception-looking popup window as soon as hit the first line of code.

The reason that this MDA is so useful is that it is really quite difficult to determine for certain which binding context an assembly was loading into, other than following a certain set of rules and closely watching the way that the binder binds to dependent assemblies. However, with this MDA, you can know for sure if you are loading assemblies into the LoadFrom context.

There are several other MDAs to play with. I recommend taking a look through them and turning on ones that might apply to your program. There is no harm and you may avoid your program throwing an exception in some edge-case scenarios for reasons that may not be super clear to you.

A few of us are heading to Phoenix in a week to visit companies and user groups interested in or currently deep into .NET Framework development. Our schedule is fully booked, but we can likely make some time still (there are three of us) if you are going to be in Phoenix during that time and would like to meet someone from the CLR team to talk about various aspects of .NET Framework development. Mail me if you are interested. There is also BetaDays happening on the thursday of that week. See Brad's post for more about that. Scott Guthrie, the Product Unit Manager of ASP.Net, will be at BetaDays and will be coming along with us to visit with one of the companies, which happens to be quite deep into ASP.Net-based development.

Brad also has an interesting post and links to many others about his Atlanta trip last week. It sounds like Brad, Kit, Claudio and Jason had an amazing time, at least judging from all the blog posts.

We're (the Phoenix tripsters) meeting the Atlanta tripsters later this afternoon for drinks to get some tips and feedback from their recent trip. It should be interesting to hear how everything worked out after a week of intense interaction with the Atlanta community. From the pics, it looks like everyone was having a lot of fun. 

There are a set of other trips still in the process of being booked. Please ping me if you've got some compelling reasons (bunch of companies using or wanting to use the .NET Framework, active usergroup(s), good restaurants)for us to come visit your city.

Phoenix, here we come!

Brad sent me mail on Friday night asking about our plans (or non-plans) to change the assembly version number again for Whidbey. The mail was the result of a developer -- let's call him Marc -- who had pinged Brad earlier in the week through his blog asking that exact question ...

Here is the basic question from Marc:

I'm glad to hear that Marc likes Whidbey. That's definitely the plan from building 42 (where the CLR team works)! Back to the original question: will Marc's app continue to work or is a re-compile required? Marc isn't specific about which beta he is using, so I'm going to have to resort to a multi-part answer, unfortunately ...

1. If Marc is on Whidbey Beta 1 (or earlier), then the answer is "yes ... a recompilation is in your future".

2. If Marc is on Whidbey Beta 2 (or later), then the answer is "no ... your app should work just fine".

W/rt (2), I do recommend re-compiling against the final product even though it isn't strictly required (from a technical perspective). Naturally, there will have been further changes/fixes in the compilers and the metadata sub-system that will very likely result in a better built assembly.

Some of you might wonder what this is all about. I'll attempt to explain w/o going on any tangents. Please email if there are some tangents that you are interested in ;)

We set the assembly version number of each of the assemblies (all the same version fortunately) in the .NET Framework at major milestones, treating it as an contract between the .NET Framework and it's consumers. We then break that contract by changing the assembly version number again when we start a new milestone (i.e. Beta 1 versus Beta 2; Everett versus Whidbey). Why do we do that? We change the assembly version number for two reasons: (A) the contract has changed since the code inside the assemblies is very substantially different, and (B) a strong identifier (i.e. a version number) needs to be changed to remain a strong identifier.

We changed the assembly version number last early in the Beta 2 milestone, for the reasons described above. We will not change it again in the Whidbey product since the rate of changes to the product has slowed down and because we only want to make changes at this point that are absolutely required to ship the product.

As a result of how we've changed the assembly number and since the assembly binder binds strictly on the whole version number, apps built with Whidbey Beta 2 will continue to reference Whidbey RTM .NET Framework assemblies since their version number will be the same as what the Whidbey Beta 2 app is expecting.

Hope that helps Marc!

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?