Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

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

Download

Right click “Save as…”

.NET compatibility is a big issue. Will your 2.0 apps work on 1.1 runtimes? Or, will your 1.1 apps work on the new 2.0 runtimes? What about apps hosted inside Outlook?

Jesse Kaplan, program manager on the .NET CLR team, covers all these application compatibility issues and more. At about 32:00 he takes us over to meet Robert Villahermosa, SDET, who demonstrates some of the places where the team has seen apps that have failed to work properly.

Tag:

Follow the Discussion

  • 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

  • Kevin DalyKevin Daly Because.
    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.
  • MauritsMaurits AKA Matthew van Eerde
    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.
  • scobleizerscobleizer I'm the video guy
    Here's the Microsoft .NET Framework 1.1 and 2.0 (Beta) compatibility whitepaper that we promised to link to during the video.
  • MauritsMaurits AKA Matthew van Eerde
    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.
  • scobleizerscobleizer I'm the video guy

    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?

  • MauritsMaurits AKA Matthew van Eerde
    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.
  • Mike SampsonSampy And I come back to you now - at the turn of the tide

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

  • 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?)

  • scobleizerscobleizer I'm the video guy
    mrpeabody: you're right, I'm sorry about that.
  • MinhMinh WOOH!  WOOH!

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

  • Chris PietschmannCRPietschma​nn Chris Pietschmann
    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

Remove this comment

Remove this thread

close

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.