Early warning on obsolete members coming in .NET Framework 2.0 (Whidbey)

Obsoleted Members in Whidbey Framework 2.0

Sam Gentile's Blog — Thu, 22 Apr 2004 08:42:00 GMT

re: Early warning on obsolete members coming in .NET Framework 2.0 (Whidbey)

PeteB — Thu, 22 Apr 2004 07:11:00 GMT

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.

re: Early warning on obsolete members coming in .NET Framework 2.0 (Whidbey)

Len Weaver — Thu, 22 Apr 2004 07:48:00 GMT

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.

Membri obsoleti in .NET Framework 2.0

Maurizio Tammacco Blog — Thu, 22 Apr 2004 15:55:00 GMT

re: Early warning on obsolete members coming in .NET Framework 2.0 (Whidbey)

Ernst Kuschke — Thu, 22 Apr 2004 14:12:00 GMT

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

Obsolete members in Whidbey

Ernst Kuschke — Thu, 22 Apr 2004 17:14:00 GMT

Early VS2005 deprecation info (by yag)

VS Data Team's WebLog — Thu, 22 Apr 2004 18:39:00 GMT

re: Early warning on obsolete members coming in .NET Framework 2.0 (Whidbey)

Roy J. Salisbury @ VsDevCentral — Thu, 22 Apr 2004 16:55:00 GMT

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.

re: Early warning on obsolete members coming in .NET Framework 2.0 (Whidbey)

Junfeng Zhang — Thu, 22 Apr 2004 17:27:00 GMT

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 (http://blogs.msdn.com/suzcook) for more information.

re: Early warning on obsolete members coming in .NET Framework 2.0 (Whidbey)

Kit George [Microsoft] — Thu, 22 Apr 2004 17:26:00 GMT

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.

re: Early warning on obsolete members coming in .NET Framework 2.0 (Whidbey)

Sriram Krishnan — Thu, 22 Apr 2004 17:48:00 GMT

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

re: Early warning on obsolete members coming in .NET Framework 2.0 (Whidbey)

Steve Maine — Thu, 22 Apr 2004 19:31:00 GMT

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?

re: Early warning on obsolete members coming in .NET Framework 2.0 (Whidbey)

Suzanne Cook — Thu, 22 Apr 2004 22:50:00 GMT

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 http://blogs.msdn.com/suzcook/archive/2003/05/29/57137.aspx 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 http://blogs.msdn.com/suzcook/archive/2003/05/30/57159.aspx . Basically, the use of LWPN() causes a serious side-by-side bug in your code.

re: Early warning on obsolete members coming in .NET Framework 2.0 (Whidbey)

Kevin Westhead — Thu, 22 Apr 2004 23:09:00 GMT

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.

Obsoleted Members in Whidbey Framework 2.0

Marcus Mac Innes' Blog — Fri, 23 Apr 2004 15:09:00 GMT

re: Early warning on obsolete members coming in .NET Framework 2.0 (Whidbey)

Ken Cowan — Fri, 23 Apr 2004 12:34:00 GMT

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

re: Early warning on obsolete members coming in .NET Framework 2.0 (Whidbey)

Ernst Kuschke — Fri, 23 Apr 2004 13:19:00 GMT

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

Obsolete Members in .NET V2.0.

Code In Zen — Sat, 24 Apr 2004 06:42:00 GMT

Obsolete members inside .Net Framework 2.0 (Whidbey)

Kevin's Blog — Mon, 26 Apr 2004 03:28:00 GMT

Obsolete members inside .Net Framework 2.0 (Whidbey)

Kevin's Blog — Mon, 26 Apr 2004 03:28:00 GMT

FW: Obsolete members coming in .NET Framework 2.0

Lance's Whiteboard — Fri, 30 Apr 2004 03:55:00 GMT

More on Whidbey API deprecation (by yag)

VS Data Team's WebLog — Sat, 01 May 2004 04:28:00 GMT

re: Early warning on obsolete members coming in .NET Framework 2.0 (Whidbey)

secretGeek — Tue, 04 May 2004 03:53:00 GMT

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

Membri obsoleti in .NET Framework 2.0

Maurizio Tammacco's Blog — Fri, 14 Jan 2005 16:04:00 GMT

Twenty questions

IWebThereforeIAm — Thu, 05 Jun 2008 04:03:06 GMT

[Twenty questions] [Thread.Suspend/Resume)] [Worker thread wrapper class] [Winforms: merge and acceptChanges] dsChanges = dsOriginal.GetChanges(); CallToDBUpdateMethod(dsChanges); dsOriginal.Merge(dsChanges);...

Brad Abrams Early warning on obsolete members coming in NET | Quick Diets

Brad Abrams Early warning on obsolete members coming in NET | Quick Diets — Tue, 09 Jun 2009 13:46:22 GMT

PingBack from http://quickdietsite.info/story.php?id=8401