Jesse Kaplan -- Will your .NET 1.1 apps work on 2.0 or vice versa?

I've tried all my ASP.NET apps (15+) out on 2.0, and in about five only minor, straightforward changes were necessary to get them working.  Some that crept in from the conversion tool.  Altogether the feeling I get is, "It just works!"

So I'm sold 100% on Whidbey.  I hope that there aren't any crazy hacks going in just to try to maintain compatibility with 1.1.  2.0 adds lots under the hood, and I actually expect some things to break.  And it's all for the better.  Now I've got generics at my disposal!  Thanks, CLR guys for that.  I know that wasn't easy.

I've also got the better ASP.NET architecture with partial classes.  I can now revise lots of my existing code to leverage some of the new controls, and better compatibility with Netscrape and Firefox.

Thanks for bringing us a great update!

-Lorin

This is the best explanation I've seen so far of not only what the compatibility scenarios are but also of why they are the way they are.

Much appreciated.

The terms "backwards compatibility" and "forwards compatibility" depend completely on your POV, which is why Scoble was confused.

Consider a .NET 1.1 control trying to run against a machine that has the .NET 2.0 Framework installed.

From the POV of the control author, this requires "forwards compatibility" on the part of the control.  ("Backwards compatibility" for the control author would be if the 1.1 control worked on the 1.0 Framework.)

From the POV of the .NET team, this requires "backwards compatibility" on the part of the framework. ("Forwards compatibility" for the Framework team would be if a 2.1 app ran on the 2.0 Framework.)

Backwards compatibility is much easier - just requires testing against things that already exist.

Forwards compatibility usually requires either rigid standards or psychic powers.

Here's the Microsoft .NET Framework 1.1 and 2.0 (Beta) compatibility whitepaper that we promised to link to during the video.

Hmmm... what about 1.0?  Has that been abandoned?

If I put up a 1.1 control in my web app and someone calls me saying it doesn't work... and I determine they're running the 1.0 Framework and they've hit a breaking change... can I tell them "Microsoft says you have to upgrade to 1.1?"

I'd suggest upgrading to 2.0 beta, of course, except that I'm leary of asking customers to install beta software.  Call it EULA shock.

Yes, if your 1.1 app doesn't work when running on the 1.0 runtimes and upgrading to 1.1 runtimes gets it to start working, that seems like a good thing to recommend, no?

But, most of those problems have been hit already since 1.1 has been out there for awhile.

What happens if a program makes a call to a .net DLL that was complied on version 1.1 form 2.0? Does the DLL run in 1.1 or 2.0, and dose it matter if it’s a compile type reference or late binding?

scobleizer wrote:

Yes, if your 1.1 app doesn't work when running on the 1.0 runtimes and upgrading to 1.1 runtimes gets it to start working, that seems like a good thing to recommend, no?

Sure.  I am comfortable with asking people to upgrade 1.0 to 1.1, just wondered if there was an official "1.0 is no longer supported" message out there... and what exactly the user would experience if they tried to run 1.1 apps on a 1.0 Framework.

EDIT: you see, this kind of thing happens all the time in the web world... someone installs Flash 5, then a few years later they try to run a Flash 7 .swf and it fails... silently...
And don't get me started on the Java runtime.  .NET, being a little young in the version sense (not yet 2.0,) is yet to experience this kind of thing on a massive scale.

Oh, and Robert was of course using Tab Completion to type those long filenames... works in XP and bash out-of-the-box, requires a registry hack in NT and 2000

EDIT2: Since the CLR version of all .NET-enabled browsers is listed in the User-Agent header (danger, Will Robinson...), a savvy log-analysis tool should be able to report on the percentage of visitors with 1.0 installed vs. 1.1 or 2.0.  What does Channel9's user-base look like?  What percentage has

No .NET CLR: ??%
1.0-ish: ??%
1.1-ish: ??%
2.0-ish: ??%
?

Damn it Scoble, VB programmers are not oblivious to MTA vs STA.  I know it was a slip of the tongue that you tried to catch, but perpetuating the myth that all VB programmers are beginners with limited ability (yes, in the video with Amanda too, it's not the first time you've done it), doesn't help raise the profile and acceptance of the product.

Sampy wrote:

Programous: There is only 1 instance of the Framework per-process. Once it's loaded, it cannot be unloaded. First Framework loaded is the one that wins. If you load a 1.1 DLL into a process with the 2.0 Framework already loaded, it will run on the 2.0 Framework (the 2.0 CLR as well as the 2.0 DLLs such as System.dll and System.Data.dll since the Framework is unified).

Hummm. I guess your right, so that would instantly make it impossible to use a 2.0 component with a 1.1 program, unless it was on a 2.0 only system, or there’s a way to tell the framework to load the newest version (maybe an app.config setting?)

mrpeabody: you're right, I'm sorry about that.

Just a thought, side-by-side execution should be called "sideway compatibility".

Programous wrote:

Sampy wrote: Programous: There is only 1 instance of the Framework per-process. Once it's loaded, it cannot be unloaded. First Framework loaded is the one that wins. If you load a 1.1 DLL into a process with the 2.0 Framework already loaded, it will run on the 2.0 Framework (the 2.0 CLR as well as the 2.0 DLLs such as System.dll and System.Data.dll since the Framework is unified).

Hummm. I guess your right, so that would instantly make it impossible to use a 2.0 component with a 1.1 program, unless it was on a 2.0 only system, or there’s a way to tell the framework to load the newest version (maybe an app.config setting?)

Yes, you can specify in the app.config which versions of the CLR are supported or even required by your app.

<?xml version ="1.0"?>
 <configuration>
    <startup>
         <requiredRuntime version="v1.0.3705"/>
         <supportedRuntime version="v1.0.3705"/>
     </startup>
 </configuration>


http://blogs.msdn.com/suzcook/archive/2004/05/14/132022.aspx

There is a registry entry that needs to be added to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework . I will have to look it up... it is something like UseOnlyLatestCLR. The value should be set to 1 to use only 2.0 when it is installed side-by-side.

I was over in the Devlab - Compatibility Testing at the end of March, we found some breaking changes, and had an awesome time, met up with Jesse and Rob and others

they are a great bunch of people, if any of you out there have any .net 1.1 apps, sign up for compatibility testing as detailed in the video. You wont regret it and you'll come away with a lot more knowledge and appreciation of the work involved in Backwards and Forwards compatibility and the wide variety of breaking changes.

i blogged the whole experience...

Day 1: http://www.costall.net/blog.aspx?BID=1057
Day 2: http://www.costall.net/blog.aspx?BID=1058
Day 3: http://www.costall.net/blog.aspx?BID=1060
Day 4: http://www.costall.net/blog.aspx?BID=1061
Day 5: http://www.costall.net/blog.aspx?BID=1062
Day 6: http://www.costall.net/blog.aspx?BID=1063

In a side-by-side scenario, it is very easy to go to IIS and set the version of framework your web application will be running.

How can I do it with Cassini? I assume I will have to compile it in 1.1 and listen to some port for my 1.1 web apps and compile it in 2.0 and run it listening in another port for my 2.0 web apps. Right?

Thank you,
Luciano Bargmann