The Good and the Bad: Obsoletion in the Framework

  • Article

You are likely familiar with this error message:

Program.cs(969,9): warning CS0618: System.Collections.CaseInsensitiveHashCodeProvider' is obsolete: 'Please use StringComparer instead

You get it when you use a Type or member in the Framework that we have applied the ObsoleteAttribute to. In Whidbey Beta1 there are a bunch of places (notice, many of these are pre-release noise and will not be in the final product). In each case we have some significant improvements to the framework that we want to have a clear way to communicate to developers.

This works great if you are working on a new app, if you happen to stumble upon using some “old” functionality you get a warning can easily move to the new stuff.

However if you are porting some very large code from V1.1 to V2.0 you could get a number of warnings about obsoleted stuff. Because we have a very high level of backwards compatibility with the framework, in almost all cases you don’t HAVE to move to the new feature, but there are good reasons to do so. So you could easily take an app that builds clean (no warnings) on V1.1 to 100s of warnings in V2.0 none of which HAVE to be fixed.

 

So the questions for you:

1. Have you run into this problem yet? Do you expect you will?

2. Do you think the value you get out of the warnings makes up for the pain of dealing with them?

3. Are we obsoleteing too much stuff in the Framework in V2.0?

4. Would you rather see obsoletes done via FxCop rather than in the compilers

 

 

Update: JasonZ (CLR PUM) chimes with a clear opinion on this… Love to hear your comments on his post as well…

Update: More feedback from TheServerSide