Obsolete in Whidbey…


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">At my href="http://download.microsoft.com/download/3/8/1/38198a72-294d-46c3-93ba-faee5cf85d00/ARC200.ppt">.NET
Framework Overview presentation at the PDC someone asked me for a list of
the members we are obsoleting in Whidbey. style="mso-spacerun: yes"> The idea being if we tell you now what
will be obsoleted in Whidbey you will have more information about what to use
today.   ns = "urn:schemas-microsoft-com:office:office" />


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> 


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">We are working on an official list
and we will ship it with Beta1 of Whidbey… but until then I have created a href="http://www.gotdotnet.com/team/brada/ObsoletedInWhidbey.htm">dirty read
version.. This is NOT the official version and you should expect changes in
this list (adds, changes, removes). style="mso-spacerun: yes"> I wanted to get you the earliest
information possible.


style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Just to be clear, these members are
still in Whidbey, applications built against them will continue to work, but
when you recompile you will be asked to move to the updated
version.

Comments (8)

  1. Keith Patrick says:

    Only one thing really jumped out at me: Hashtable(void) is going away. Curious as to why the requirement of an IKeyComparor instead of just depending on .Equals (assuming I’m understanding what IKeyComparor does…I’ve only seen the Java implementation of a hashtable)

  2. Mark Hurd says:

    Yes, the simple Hashtable and SortedList constructor is powerful for simple code, such as what I’ve thrown together using DotLisp (http://sourceforge.net/projects/dotlisp/).(See the histo and print-histo routines in my extra.lisp ‘patch’ for simple histogram construction using Hashtable and SortedList.)

    Of course, in VB.NET you could specify a default value for the constructor’s argument(s), but that’s not available for other languages, which is why I thought simple overloads like these were specified.

  3. Mark Hurd says:

    Oh and what is "dirty read" — I’ve heard "quick & dirty" and I understand you mean "pre-alpha" and subject to change, etc, but huh?

  4. Matt Hawley says:

    Do you know if there will be any backwards compatability for controls/sites currently using System.Web.UI.Page.~ instead of ClientScript.~ ? If you depreciate this, its going to be a pain in the neck for all server control developers wanting to have v1.0 or v1.1 control sets running on v1.2 (or whatever version it is called).

  5. I don’t understand why all the properties on Process need to have xxx64 counterparts.. If users are advised to use the 64 variants when they compile, then why not just change the original properties to be "long" instead of "int"? That way the API would stay clean and developers would still get a compiler error showing them what to fix. Old apps can always still run on the 1.1 framework if they were compiled with /checked and can’t handle getting a long back from those properties.

  6. Better yet, why not have the CLR automatically insert the equivalent of "unchecked { }" around those properties at runtime if the app was built against a pre-2.0 framework? That way, the return value would be the same as the non-64 variant of the property for old apps and new apps would get the long value — and the API would stay clean. 🙂

  7. Kit George [MSFT] says:

    With regards to the addition of the 64 bit values on Process Josh, we can’t simply remove the existing entries. We have fairly strong compatibility guidelines, and removing the existing entries will break apps, even if they’re written within unckeced blocks (this is because code binds against a specific interface, and changing an int to a long for a return type breaks that interface).

    I have added a comment to this affect in the whitepaper you can find on the BCL website, on Process (it will be available to view later today):
    http://www.gotdotnet.com/team/clr/bcl/TechArticles/techarticles/processfaq.doc