|
Sponsored Links
Resources
.NET Research Library
Get .NET related white papers, case studies and webcasts
|
News
News
News
|
Messages: 8
Messages: 8
Messages: 8
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Feedback: Obsolete Types/Members in .NET Framework
Microsoft and the CLR and C# teams are seeking feedback from TSS.NET readers on how we handle obsolete types\members in the .NET Framework.
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:
- Have you run into this problem yet? Do you expect you will?
- Do you think the value you get out of the warnings makes up for the pain of dealing with them?
- Are we obsoleteing too much stuff in the Framework in V2.0?
- Would you rather see obsoletes done via FxCop rather than in the compilers?
|
|
|
Message #142198
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Its a fact of life
As the platform matures obsoletion is inevitable. One thing I really want to see is a clear and immediate indicator of what the obsolete artifact has been replaced by. It’s such a pain seeing deprecation warnings and then having to embark on tedious searches trying to find out what the deprecated code has been replaced by. I know this gets more complex when blocks of functionality are rendered obsolete but at least provide a pointer to the new approach. It also means people are more likely to port the code so reducing the lifetime of the obsolete code.
I would favour the compiler handling obsolete artifacts, if the code is not going to be changed or the warnings become annoying, pragma them out or provide an -obsolete flag for the compiler.
What is also a concern is the eventual removal of deprecated code from the SDK. Who decides when, if ever, backward compatibility is no longer a requirement? How is the extraction to be handled? Is the code gone forever or moved to some form of obsolete container assemblies, external to the SDK but still available for those who cant/wont port to the new version, perhaps the deprecated sources can be made available?
I don’t want to see hundreds of obsolete methods and classes build up in the SDK so I would favour removal sooner rather than later. I would also favour total removal to ease maintenance even though I appreciate this inconveniences larger codebases as well as those who cant/wont port, leaving them constrained to building against older versions of the SDK.
|
|
|
Message #142215
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Obsolete Code
Well we have this very same issue within the company I work for. I have created new components that have made old components obsolete. We have implemeneted a component that will check existing code and see if any obsolete code is in use and form that point generate a report. Then when our prioriites allow we migrate those pieces over to the new functionality. I like Marty's idea of taking obsolete components and putting them into there own assemblies or releasing the source so we can recreate those assemblies. I think this could be beneficial for users who do not wish to modify there code or those who are unable too. I like the obsoleteattribute, however I again wish there was a more definitive way to be warned about usiong obsolete framework components. Esepcially when you are compiling multiple projects. Again I think some type of component that could validate your code would be handy. It would be super nice if this component integrated with the IDE as well as being able to be called from a command window. That is my .02
|
|
|
Message #142216
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Oh the answers to the questions
Have you run into this problem yet? Do you expect you will?
Yes, and definitly.
Do you think the value you get out of the warnings makes up for the pain of dealing with them?
Yes most definitly.
Are we obsoleteing too much stuff in the Framework in V2.0?
Ehhh I don't think so. Change must happen, just give us the ability to deal with the change.
Would you rather see obsoletes done via FxCop rather than in the compilers?
Both.
|
|
|
Message #142234
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
It's quite simple really.
Take a look at how Eiffel (www.eiffel.com) solves this. Eiffel uses a reserved word ("obsolete") that can be applied to a class or to one or more features of a class. One can add a comment after "obsolete" (much like one can with "region" in C#/VB.Net) and the presence of an "obsolete" clause triggers a compiler warning and if the comment is present it will be displayed as part of the warning. It is important to remember that one should only mark truly obsolete features/classes obsolete and not use obsolete as an excuse for not fixing e.g. broken features.
Example:
class BAD
obsolete -- "This class will be removed on the 22nd of October. Please use class GOOD instead".
Regards,
Eirik M.
"If I can't Eiffel in heaven, I won't go"
|
|
|
Message #142235
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Answers to the questions
Forgot to answer the questions :-)
1) yes
2) yes
3) don't know
4) compilers
Regards,
Eirik M
"If I can't Eiffel in heaven, I won't go"
|
|
|
Message #142237
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Errr, learn from Java???
>> Have you run into this problem yet? Do you expect you will?
I havent hit this problem in C# yet - probably because I havent done enough work in C#....
But I have in Java - and there is no reason to suggest that C# wont mature (and hence deprecate apis/classes) in the same way. Its a fact of life when you have such rich set of runtime libraries.
>> Do you think the value you get out of the warnings makes up for the
>> pain of dealing with them?
Are the warnings that big a deal?
The java compiler has a -deprecated flag... (which turns the warnings on). That model seems to work fine...
>> Are we obsoleteing too much stuff in the Framework in V2.0?
I dont know. Stands to reason it will happen. Its early days for C#. The same kind of churn happenned in Java's early days... from 1.0 to 1.2 for example...
>> Would you rather see obsoletes done via FxCop rather than in the compilers?
The compilers are fine.
The IDE should should also syntax-highlight deprecated method/Type usage - save having to wait until compile time...
The one thing that everyone values in the Java Runtime Libraries (despite the fact that they simultaneously complain about it) is the fact that no (zero) (0) classes/methods have been removed since it was released.
Backwards compatibility has been a fundamental principal.
People may whinge if you leave a bit of cruft in the libraries - but they will ureservedly hate you if a CLR upgrade breaks their app.
-Nick
|
|
|
Message #142261
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Answers to the questions
Forgot to answer the questions :-)1) yes2) yes3) don't know4) compilersRegards,Eirik M"If I can't Eiffel in heaven, I won't go" Ditto.
It would be cool to have a voting tool for this instead of requiring posts...
- Chris
|
|
|
Message #142415
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
You are right on Nick
Depricating functionality when you are running an enterprise costs the company a lot of money, with usually little beneficial gain. If you are an architect, you need to think of the unintended consequences (think ahead) and not depricate because someone found a better way (or worse yet, just a different way). This is especially true if you are architecting frameworks which would affect most of your enterprise.
|
|
|
| |
|
| New content on TheServerSide.NETNew content on TheServerSide.NETNew content on TheServerSide.NET |
|
|
Language "mashups" will become more prominent, and developers will become polyglots, one programmer suggests.
SearchWinDevelopment.com offers an introduction to the language, performance, testing and data management improvements in VS 2008.
VBCode.com code snippets cover all aspects of application development, from data binding to security to the user interface.
Get up to date on XAML best practices with a variety of articles, tutorials and webcasts. [SearchWinDevelopment.com]
One team's experience with the VSTS DB edition suggests that it can improve workflow for dev teams. It also enhanced Agile efforts.
(June 24, Article)
Microsoft has begun to include DSL tools in the VSTS kit. A new book by Steve Cook and other VSTS team members helps set the stage.
(June 24, Article)
Cartoon: Be it ever so humble there is no place like your home after you get a Microsoft Home Server .
(June 18, Cartoon)
Microsoft's Thom Robbins says new technology to highlight in NET 3.5 includes AJAX, LINQ for both C# and VB, as well as tooling enhancements intended to ease the task of building WPF, WF and WCF apps.
(June 29, Podcast)
Venkat Subramaniam discusses AJAX bottlenecks, the tenets of Agile development and more. He spoke at the Ajax Experience.
(June 25, Tech Talk)
In the second of a two-part series, Michele Leroux Bustamente discusses design decisions related to the claims-based security model. Read the story and walk through the process for creating a set of claims-based utilities to encapsulate claims authorization at the service tier.
(May 24, Article)
Understanding why the Entity Framework exists and learning where it can fit into your projects can get you prepared for the eventual release early next year.
(May 10, Article)
Resource: This learning guide gives you quick access to useful links on Windows Communication Foundation security information.
(April 24, Article)
TSS.NET's Jack Vaughan spoke recently spoke with Microsoft's Brad Abrams to find out what he is seeing in the field and what the chefs in Redmond are cooking. Along the way he discusses patterns of AJAX frameworks.
(April 11, Article)
In a two-part series, Michele Leroux Bustamente explains how claims-based security is supported by WCF, and how you can implement a claims-based security model for your services.
(March 29, Article)
Windows Workflow Foundation is a new technology that many developers will need to get their heads around. In a brief excerpt adapted from Programming Windows Workflow Foundation: Practical WF Techniques and Examples using XAML and C#, K.Scott Allen considers aspects of workflow definition.
(March 22, Chapter Excerpt)
|
|
