views:

400

answers:

11

OK, this kind of follows on from my previous question.

What I would really like to do is create some sort of attribute which allows me to decorate a method that will break the build. Much like the Obsolete("reason", true) attribute, but without falsely identifying obsolete code.

To clarify: I dont want it to break the build on ANY F6 (Build) press, I only want it to break the build if a method decorated with the attribute is called somewhere else in the code. Like I said, similar to obsolete, but not the same.

I know I am not alone in this, since other users want to use it for other reasons. I have never created custom attributes before so it is all new to me!

A: 

This is all starting to sound a bit like Yesterday's TDWTF. :-)

Ross
A: 

@Ross,

LOL! Exactly what I was thinking as I was writing it! Great timing huh? :)

Rob Cooper
+2  A: 

If you consider a warning (which is what [Obsolete] throws up) build-breaking, then just use the #warning compiler directive.

Edit: I've never used it, but #error is also available.

Thomas G. Mayfield
A: 

Why not just make something up? An unknown attribute would surely break the build.

[MyMadeUpAttributeThatBreaksTheBuildForSure]
public class NotDoneYet {}
Greg Hurlman
A: 

@Greg

Sorry, I should have been more clear with the requirements. Your suggestion would break EVERY build, I only want to to break the build if the decorated method is used.

Question updated.

Rob Cooper
A: 

I will have to agree with Greg: make up an attribute for it.

And if you're really serious, maybe find a way to figure out if the constructor is being accessed by anything other than XMLSerializer and throw an exception if it is.

Jon Limjap
+4  A: 

If this is for XML serialization and NHibernate, where you want the parameterless constructor to be accessible (as is the case in the example you referenced), then use a private or protected parameterless constructor for serialization, or a protected constructor for NHibernate. With the protected version, you are opening yourself up to inherited classes being able to call that code.

If you don't want code calling a method, don't make it accessible.

EDIT: To perhaps answer the deeper question, AFAIK the compiler only knows about three attributes: Obsolete, Conditional, and AttributeUsage. To add special handling for other attributes would require modifying the compiler.

Thomas G. Mayfield
Following some digging on Google, it looks like you are right, the build-breaking ability of Obsolete is actually compiler magic rather than coded attribute magic! Damn!
Rob Cooper
A: 

I'd suggest you to use the #error directive.

Another pretty unknown attribute that might do the work is the conditional attribute (depending on what you're trying to ahieve)

[Conditional("CONDITION")] 
public static void MiMethod(int a, string msg)

which will remove the method invocation from the IL code itself if "MY_CONDITION" is defined.

Jorge Córdoba
A: 

Create an FxCop rule, and add FxCop to your integration build in order to check for this.

You'll get warnings, rather than a failing build. Attributes 'run' at reflection time rather than build time.

Alternatively (and this is rather nasty) put a compiler directive around the method you don't want to be called. Then your code will break if you call it, but you can set up a build that passes the right compiler directive and doesn't.

Keith
+1  A: 

I think the only fool proof way would be to extend the Visual Studio (through VSIP) and subscribe to the correct event (maybe in the EnvDTE.BuildEvents) class, and check your code for usage of the constructor, and cancel the build if you detect it.

Vaibhav
+2  A: 

I think this would be an excellent feature request for Microsoft: Create an abstract base class attribute CompilerExecutedAttribute that the compiler processes in some manner or that can influence the compiling process. Then we could inherit from this attribute and implement different operations, e.g. emit an error or a warning.

Konrad Rudolph