The meaning of obsolete

Question

I've taken over a project with a lot of legacy code, both C++ and C#, currently compiling under VS 2010 (on windows 7).

When I built my solution, amazingly, 143 projects built successfully. However, there were a boat load of warnings. A surprising number of them were warning about obsolete functions.

warning CS0618: 'System.Runtime.InteropServices.UCOMIMoniker' is obsolete
warning CS0618: 'System.Runtime.InteropServices.UCOMIEnumMoniker' is obsolete
warning CS0618: 'System.Runtime.InteropServices.UCOMIRunningObjectTable' is obsolete
warning CS0618: 'System.Runtime.InteropServices.UCOMIRunningObjectTable' is obsolete
warning CS0618: 'System.Runtime.InteropServices.UCOMIBindCtx' is obsolete
warning CS0618: 'System.IO.Path.InvalidPathChars' is obsolete
warning CS0618: 'System.Configuration.ConfigurationSettings.AppSettings' is obsolete
warning CS0618: 'System.Net.Dns.GetHostByName(string)' is obsolete

What is meant by this? The functions are clearly still defined or they wouldn't compile or would give me some sort of 'not found' or 'not defined' error. Are the implementations missing? Do these functions still work (as well as they used to)?

Several I have looked up and they've been obsolete for a long long time. For example, GetHostByName :

.NET Framework

Supported in: 1.1
Obsolete (compiler warning) in 4.6
Obsolete (compiler warning) in 4.6
Obsolete (compiler warning) in 4.5
Obsolete (compiler warning) in 4.5.1
Obsolete (compiler warning) in 4.5.2
Obsolete (compiler warning) in 4
Obsolete (compiler warning) in 3.5
Obsolete (compiler warning) in 3.5 SP1
Obsolete (compiler warning) in 3.0
Obsolete (compiler warning) in 3.0 SP1
Obsolete (compiler warning) in 3.0 SP2
Obsolete (compiler warning) in 2.0
Obsolete (compiler warning) in 2.0 SP1
Obsolete (compiler warning) in 2.0 SP2

If I understand that right, its been obsolete for the last 8-9 years(.NET 2.0 came out in 2006). Why hasn't anyone fixed these? Do they need to be fixed? When I researched that GetHostByName method, its replaced with GetHostEntry. Easy enough... but hold on, there are lots of people complaining that it doesn't work the same with the new function and maybe you should replace it with a call to GetHostAddresses instead. Well, dang.

Given that I've got over 28k files in my solution, I'm not sure I can just go messing with things willy nilly. Is there way to know how long obsolete functions will be supported for? Should I expect that these will even work once I get the system installed? What are the system implications of having code invoke obsolete interfaces (MSDN)?

I am not trying to understand how to remove obsolete code from my own system, but how systems are supposed to deal with obsoleted interfaces on external systems (eg. MSDN). They clearly are not following a simple cycle of marking obsolete, replacing, and deleting old interfaces. What is their policy? How should users of MSDN defined interfaces react to the obsolete tag, particularly when the obsoleted code isn't replaced with an 'apples to apples' equivalent function.

Answer 1

Often classes or methods get marked as obsolete as they will be deprecated in the next release or are no longer the most efficient way to do a certain task. However, Microsoft often leaves these methods for a long time to guarantee backwards compatibility.