Dealing with Obsolete Code
Last week I did my first serious work with VS2005. Sure, I've played a lot with it, and compiled and run and tested a hell of a lot of different snippets and played with a lot of new features, but on Friday I started working on converting all our base libraries to the 2.0 framework.
Not surprisingly, there was very little that was problematic, and what problems were there were easily diagnosed with help from the built in FxCop engine.
The first main problem was that a couple of classes had a method called Continue, which is now a keyword in VB2005. Easily fixed by wrapping a pair of square brackets around it to escape it: [Continue].
The second to look at was a whole heap of warnings that a variable might be used uninitialised. In all cases it reported this problem, it wasn't actually a problem - they were all tests for Nothing. A while back we decided that initializing reference types to Nothing explicitly was really a waste of time, since the framework guarantees this anyway. As soon as an explicit set to Nothing was added, the warning went away. I'm still undecided what to do here - I like having no warnings, and I don't want to disable this one, but having to add extra code just to satisfy FxCop is annoying (although it's really no big deal).
Then there was the reports of things were now obsoleted. This is an interesting one. The people that control the framework API's have decided that there's some calls that were available in the 1.0/1.1 framework that really shouldn't be called anymore. Instead of taking it away and causing a breaking change, they've marked them obsolete with an ObsoleteAttribute.
The most common one that showed up was easy - any call I had to System.Configuration.ConfigurationSettings just needed to be changed to System.Configuration.ConfigurationManager. Easy enough, one I worked out I needed to add a reference to the new System.Configuration.dll :)
The next one more problematic. To handle SSL certificates silently, you used to be able pass an instance of some class that implements ICertificatePolicy to the CertificatePolicy property of the ServicePointManager. Now it all different - now you pass the ServerCertificateValidationCallback property a delegate of type RemoteCertificateValidationCallback. So that's a whole class I have to re-write. No biggie, and certainly not hard :)
The last one is one that's going to take some thought. Thread.Suspend and Thread.Resume have been obsoleted.
I can understand perfectly why this has been done - and in the words of the guys that wrote the threading stuff in the first place, they never should have made it available to begin with. If some random thread comes along and suspends another one, what was that thread doing at the time it got suspended? It might be in the middle of a DB call. It might have a whole lot of different resources locked. Too many bad things could happen.
Once I thought about it, it made perfect sense. And now I need to completely rewrite how a couple of my classes work :) The advice offered has only been that some other way must be used, but not many specifics on how. The way I see it, I need to make the threads that need to be paused constantly checking to see if they have been signalled, and block themselves until the signal has been reset.
It's no big deal, but a slight perf hit.
And admittedly, the only reason I wrote a 'pause' functionality into these classes is that they're in use from a windows service, and windows services can be paused.
But all in all, I think I got off lightly. There's a fair few other things within the framework that have been obsoleted too, and we don't touch any of them. Brad Abrams gave some warning of what was coming here.