In .NET, you can mark methods and accessors as obsolete by using the
[Obsolete(msg, errflag)] directive.
I've found some interesting behavior with the directive when used in a class
which is referenced as a return type by a web service:
Consider the following class:
class foo
{
private int _bar;
[Obsolete("Obsolete. Please use bar1.", true)]
public int bar
{
get {return _bar;}
}
public int bar1
{
get {return _bar * 5;}
}
}
The true flag on the obsolete directive means that the compiler will throw
an error when someone tries to reference the bar accessor. If it is left
false, the compiler only throws a warning.
Now take this a step farther. Create a web service called FooInfo, and a
method GetFoo which returns an instance of the Foo object (prior to
obsoleting the bar accessor).
the code might look like this
FooInfo fooInfo = new FooInfo();
Foo aFoo = fooInfo.GetFoo();
When you compile this code, it will compile fine (there is no specific
reference to bar or bar1 in the code). However, when you mark bar as
obsolete, the code will still compile, but the program will crash when you
try to run it. But it won't crash on the GetFoo line. It crashes on the
constructor for the WebService. The error will look like the following:
"File or assembly name uxc_b_hj.dll, or one of its dependencies, was not
found."
The name of the dll referenced will change each time (it is a temp dll
windows uses during runtime).
If you mark bar as obsolete, and leave it as a warning, everything works fine.
I'm sure there is is good reason this works this way, but the error is
certainly misleading, and took 4-5 hours to figure out, since the turning on
the obsolete directive happened two weeks ago in a different project.
Hopefully this will save others some time.
