tags:

views:

39

answers:

2

Is there a way to somehow mark Types I do not control as Obsolete? Basically I would like to add ObsoleteAttribute to types I do not want to use in my .net Project (i.e., SerializableAttribute)

I believe I can do something like that with FxCop, but ideally I would like to have the compiler already generate warnings for "greylisted" Types?

This should be on a Per-Project level, but sadly "Extension Attributes" don't exist, and adding them at Runtime is too late for ObsoleteAttribute...

Edit: Just to clarify, I do not want to block Types from using (keep in mind that ObsoleteAttribute by default only generates a warning, not an error!), I just want to generate warnings when they are used as in 99% of all cases it's wrong to use them (i.e. SerializableAttribute). Also, I'm not only referring to .net types but also to some third party types. It's more a reminder. I'll guess FxCop is my best bet then.

A: 

No, and i tmakes sense. As they are not under your control, you are not having a right to obsolete them ;) So to say.

FxCop can not do it either. xCop can say whether you use one, but that is not the same as adding an obsolete attribute to them.

I seriously think the whole idea of types "I do not want to use in my .net project" is pretty out - becasue you will have to do a TON of work for NO result. Types not usefull are not used by definition (unless you like including stuff that you dont really need). Obsoleting them does not achieve anything.

And you may be surprised... maybe one day you need some of them.

Never been in a project where this approach was taken.

TomTom
I don't think this is a particularly helpful answer. Aside from the fact that I see no reason why this couldn't be done with an FxCop rule, you are reasoning that it shouldn't be done because you've never been in a project where it was done. I could think of some very good reasons why you might want to exclude the use of certain types from your checkin policy. For example, you might want a policy that all new types should expose DateTimeOffset instead of DateTime.
Josh Einstein
Well, helpfull or not, it is the correct answer. Reality does not bend to your will. Obsolete has a specific semantics that you intend to change - "not to be used in this project" is different from "dont use, wil be replaced/removed". Any post usage rule (FxCop) is likely the only way to do it. And you rexample is a good example of why NOT to do it: TONS of stuff exposes DateTime, and sometimes it is easier to work with a DateTime temporarily while using the existing API.
TomTom
Sometimes you need to read between the lines of a question, Tom. The OP is clearly trying to enforce a policy regarding the usage of certain types. I'm sure if a solution works, he is not married to ObsoleteAttribute. FxCop is the way to go and my example regarding DateTimeOffset is just one of many perfectly valid examples I can think of for such a policy.
Josh Einstein
The user wants to block all classes he is not using. I am sorry, but that will be more than half of the .NET framework to start with. Even if you stick to official assmeblies that is a LOT of stuff. A tremendous amount of stuff. Even using a simple file with class names in an FxCop rule it would take significant time just to put in and filter all official classes.
TomTom
I clarified the question. Note that I don't want to block them, only to generate a warning.
Michael Stum
+3  A: 

There isn't a way to do this directly; FxCop would be your best bet. You could get creative, though, and re-declare the type. Caveat: this is dodgy dodgy! But it'll work:

namespace System.Text {
    [Obsolete("Pah; who wants performance...", true)]
    public class StringBuilder { }
}

This is so nasty! But takes an extern alias to get around. It might also monkey with some string-based reflection (Activator.CreateInstance) of course.

Marc Gravell
Whow. Ok, sorry for the -1 - the solution works. But it is REALLY ugly and REALLY a lot of work and will add a HUGH blacklisting assembly basically for nothing. Yes, working, bu the side effects are hugh.
TomTom
Re the downvote - what, did I not add enough caveats for you?
Marc Gravell
@TomTom, why do you assume it will be a lot of work? I suspect there's probably only one or two types the OP wants to block. And Marc acknowledged the fact that this is an ugly hack and recommended FxCop.
Josh Einstein
Thanks. I've clarified the question. Yes, it's only a handful types (some in 3rd party libraries) that shouldn't be used, and I wanted to have something during compile. Thanks for showing a possible (ugly) solution with some caveats, I will re-consider whether or not it's really worth it or if FxCop is the appropriate place.
Michael Stum