text: We have a very cool report we run every week over the entire .NET Framework that shows which members were obsoleted. As I was reviewing that list, I thought that this would be great information to get out to customers right away. After all if you are using V1.0 or V1.1 of the .NET Framework you may not have time to pick up each of our community preview bits and try them out. By making this kind of information available to you in an easy way, it gives you a chance to get a glimpse at the changes that are coming.
  Keep in mind that these are just obsolete in V2.0, not removed, so you can still use them in 2.0, but you should start making your way off them. Also, I notice many of them suggest using members that are new in Whidbey (such as SafeHandles), clearly you can’t do anything in your codebase today to make that move.
  And, of course the standard caveats apply: this is pre-release, subject to change, etc, etc.
  I have included just MsCorLib here, assuming folks think it is interesting I will find a way to do the other DLLs as well. Feedback on the message text is also welcome….
  If Assembly.LoadWithPartialName is gone, is there any way to load with just a partial name? According to the documentation, Assembly.Load load needs the full name (or ‘long name’, as the docs refer to it), and I can recall needing to use LoadWithPartialName for something quite obscure.
  I haven’t used any of the obsoleted classes/members, so I guess I’m safe. You mentioned that you might be wiling to give us a sneak peek at other assemblies… I’d be very interested to find out what will change in the System.Data namespace. I’ve heard very little about the v2.0 data access story.
  Calling abort on an already suspended thread is a good example of a deadlock, but surely there is some loss of functionality by making Thread.Suspend & Thread.Resume obsolete???
  GetCurrentThreadId() – Message: AppDomain.GetCurrentOSThreadID has been deprecated because it does ….
  ???
  The method in the left column is GetCurrentThreadId, but the message is about a non-existant GetCurrentOSThreadID method being deprecated…
  I think the message implies that we should use Thread.CurrentThread.ThreadId .. Just I typo in the message column I guess.
  In response the obsoleting of Thread.Abort/Resume, Jonathan Keljo and Chris Brumme, Manager and Architect for the area, reply:
  We’ve never seen a sound reason for using that functionality. Most of the time, people who use Suspend/Resume are trying to do synchronization, and they get into big trouble with deadlocks.
  Synchronization is better (and more safe) with Monitor/Mutex/Semaphore.
  PeterB,
  Assembly.Load works with partial name. Just it won’t try to load random assembly from GAC. That is equivalent of dll hell in Win32. You can read Suzanne’s blog () for more information.
  Actually, I find it interesting that Java also initially had both Resume and Suspend and went ahead and deprecated both. I just find it interesting that .NET seems to have taken a similar path
  I find it sort of amusing that UnsafePack() has been obsoleted with an error message telling the user that the function is not safe. Seems sort of obvious from the method name…
  So is the new overload of UnsafePack() safe or not?
  Regarding LoadWithPartialName():
  You can load with a partial name by calling Assembly.Load(). However, you should design your app in such a way that the full display name is available for this call (see about display names). Otherwise, Load() will not be able to return assemblies in the GAC or in a v2.0 host assembly store. (Besides it just being good practice.)
  To see the reasons why it is important to use Load() instead of LoadWithPartialName(), see . Basically, the use of LWPN() causes a serious side-by-side bug in your code.
  I see that the UCOMI* types have changed to ComTypes.I*. Out of curiosity, what are the naming guidelines when importing COM types to be used across different assemblies? Should I always use the same parameter names, etc. as defined in the original COM type even though they may not match the other .NET guidelines? This would explain why there is ComTypes.TYPEFLAGS rather than ComTypes.TypeFlags, however this sort of thing does cause FxCop to complain.
  If I p/invoke to SuspendThread and ResumeThread, will I get the same behavior as today’s Thread.Suspend and Thread.Resume? In particular, will the GC know that my thread is suspended in both cases, and so permit a collection to happen?
  You need Suspend and Resume to implement the Ada Task package. There are features to enable the Ada programmer to ensure his app doesn’t live lock. Worse, the spec is written as if the OS doesn’t do preemptive multitasking. To get all this right, you need a whole lot of Suspend, Resume, fibers and synchronization objects.
  I do agree that it’s easy to deadlock. An early prototype of our performance profiler would occasionally cause deadlocks, due to the GC suspending threads while we held a critical section. I also agree you should make it as easy as humanly possible for people to write apps that synchronize threads correctly. I disagree with the decision to deprecate it, unless there is a viable alternative for a legitimate need.
  KC
  Once again it seems to be an issue of backwards compatibility biting…(!) If the "threading concept" could be designed from the ground up here, Suspend and Resume would never have existed…. (I slowly realised that today)
  But since we’ve had it before, to be compatible with many issues, it’s difficult, if not impossible, to totally deprecate the functionality.
  -Ernst
  Hi Brad — this is an excellent page, but (I have to say this) it falls so very far short!
  First off, developers who simply provide comments like ‘This is obsolete, use such and such method instead,’ should be dragged out into the yard, whipped, flogged and then, well, then the real torture should begin.
  This sort of documentation is too big an issue, to involve just the developers who make the change. If these were only internal APIs, then hell yes, this would be sufficient. But that isn’t the case..
  Each message needs to provide at least the following:
  The URL of a webpage/helpfile that explains:
  * What has become obsolete
  * Why it has become obsolete
  * What you should use instead
  * What advantage the developer will get from using the alternative. (i.e. "What’s in it for me?" — code documentation is a public relations exercise after all)
  * The page should also provide the location of a forum where FAQ relating to this change are stored, and where new questions should be asked.
  The API message should have a concise summary of the above information.
  Yes, I think this is a lot of documentation to insist on, but it would ease the effort of upgrading APIs. And to ease that effort will be a major issue with microsoft in the years to come.
  Microsoft is a grown-up now, and it should behave like one.
  cheers
  Leon
  (thanks though — this page really is a very good start!)
  [Twenty questions] [Thread.Suspend/Resume)] [Worker thread wrapper class] [Winforms: merge and acceptChanges] dsChanges = dsOriginal.GetChanges(); CallToDBUpdateMethod(dsChanges); dsOriginal.Merge(dsChanges);…
  PingBack from