How to Obsolete two related classes?

  • Thread starter Thread starter Phill W.
  • Start date Start date
P

Phill W.

If I have a reusbale (GAC-'registered') assembly that contains two,
[cross-]related classes (imagine a DataSet and DataTable; the former
contains instances of the latter, the latter has a reference to its
parent .. er .. former).

I want to make /both/ of these classes Obsolete, so I added Obsolete
attributes to both. When these are only Warnings ...

<Obsolete("DO NOT USE", False)>

.... all is well; I can compile my assembly and get Warnings if I try to
compile other code against them.

My problem, though, is that I want to make these Errors, so that people
really /really/ can't compile against them. So, I up-ed the Obsolete
attribute to be an error ...

<Obsolete("NO, REALLY - DO NOT USE", True)>

.... but now I can't compile *my* assembly, because the Obsolete classes
refer to one another!

Is there any way of doing this?
An "IgnoreObsoleteAttributeOn(System.Type)" attribute, perhaps?

TIA,
Phill W.


oone is parent
 
Phill,
I've been pondering an answer for a few days now...

The "Best" I can come up with is to decouple the relationship between the
classes. Either completely severe the relationship & let the versioning of
the GAC take care of current code. Or replace the relationship with an
interface that only has an Obsolete(false) attribute on it or an internal
interface, which would probably break existing code. Alternatively put
Obsolete(True) on each member of both types, except for the referring
members themselves.

Remember assemblies in the GAC can be (should be) versioned. I would expect
"Deleting" these two types to be the moral equivalent to a new version,
hence I would introduce a new version in the GAC, as opposed to simply
replacing an existing version.

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


| If I have a reusbale (GAC-'registered') assembly that contains two,
| [cross-]related classes (imagine a DataSet and DataTable; the former
| contains instances of the latter, the latter has a reference to its
| parent .. er .. former).
|
| I want to make /both/ of these classes Obsolete, so I added Obsolete
| attributes to both. When these are only Warnings ...
|
| <Obsolete("DO NOT USE", False)>
|
| ... all is well; I can compile my assembly and get Warnings if I try to
| compile other code against them.
|
| My problem, though, is that I want to make these Errors, so that people
| really /really/ can't compile against them. So, I up-ed the Obsolete
| attribute to be an error ...
|
| <Obsolete("NO, REALLY - DO NOT USE", True)>
|
| ... but now I can't compile *my* assembly, because the Obsolete classes
| refer to one another!
|
| Is there any way of doing this?
| An "IgnoreObsoleteAttributeOn(System.Type)" attribute, perhaps?
|
| TIA,
| Phill W.
|
|
| oone is parent
 
Jay said:
Phill,
I've been pondering an answer for a few days now...

Remember assemblies in the GAC can be (should be) versioned. I would expect
"Deleting" these two types to be the moral equivalent to a new version,
hence I would introduce a new version in the GAC, as opposed to simply
replacing an existing version.
Click to expand...
Jay,

Thanks for taking the trouble over this one.
One question about assembly versioning, if I may?

When deploying to my host servers, both application and shared assembly
files are first physically copied onto the machine's disk (from a
"Master Image" held and updated centrally), then each shared Dll is
GacUtil'ed into the Global Assembly Cache.

I've released v1.0[.0.0] of a shared Dll called, say, X.dll - well, I'm
/never/ go to have more than /26/ of these things, am I? ;-)
I have applications using this Dll.
If I release v1.1[.0.0] of a shared Dll next year, my machines will get
[shadow] copies of /both/ versions of X.dll, but taken from the same
physical source file.

But what happens to machines that are built in-between the two releases?

My "Master Image" contains /only/ the latest version (v1.1) of my shared
X.dll and only this version will be added to the Global Assembly Cache
because my deployment mechanism "registers" whatever happens to be in
the physical file. "Older" applications, expecting to use v1.0 will
therefore break, because that version "doesn't exist" (in the GAC) on
the newly built machine.

Do I really have to resort to "numbering" my physical Dll's as well, as
in ...
X.1.0.dll
X.1.1.dll
X.1.2.dll
.... in order to preserve my applications' stability over the Long Term?

TIA,
Phill W.
 
Phill,
Not sure if you are still following this thread.

Another possibly is to use ildasm.exe to disassembly the assembly into IL,
modify the attribute in the IL, then use ilasm.exe to re-assemble the
assembly

I was looking at the new compiler warnings option in 2005, however I don't
see a way in either the UI or the project file itself to have VB treat error
30668 (the error that Obsolete(True) appears to be) as a warning or to
simply ignore it...

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


| If I have a reusbale (GAC-'registered') assembly that contains two,
| [cross-]related classes (imagine a DataSet and DataTable; the former
| contains instances of the latter, the latter has a reference to its
| parent .. er .. former).
|
| I want to make /both/ of these classes Obsolete, so I added Obsolete
| attributes to both. When these are only Warnings ...
|
| <Obsolete("DO NOT USE", False)>
|
| ... all is well; I can compile my assembly and get Warnings if I try to
| compile other code against them.
|
| My problem, though, is that I want to make these Errors, so that people
| really /really/ can't compile against them. So, I up-ed the Obsolete
| attribute to be an error ...
|
| <Obsolete("NO, REALLY - DO NOT USE", True)>
|
| ... but now I can't compile *my* assembly, because the Obsolete classes
| refer to one another!
|
| Is there any way of doing this?
| An "IgnoreObsoleteAttributeOn(System.Type)" attribute, perhaps?
|
| TIA,
| Phill W.
|
|
| oone is parent
 
Jay said:
Phill,
Not sure if you are still following this thread.
Click to expand...

Oh; I'm still here ...
not all there perhaps, but still here ... ;-)
Another possibly is to use ildasm.exe to disassembly the assembly into IL,
modify the attribute in the IL, then use ilasm.exe to re-assemble the
assembly
Click to expand...

Now that's something I'd not thought about.
Now; could it really be as simple as ILDASM the assembly, Cut-and-Paste,
ILASM it back together again and Bingo! ??

I'll have a play ...
I was looking at the new compiler warnings option in 2005, however I don't
see a way in either the UI or the project file itself to have VB treat error
30668 (the error that Obsolete(True) appears to be) as a warning or to
simply ignore it...
Click to expand...

Nothing like Progress, eh? :-)

Regards,
Phill W.
 
Back
Top