I have an attribute lets call it SomeAttribute and a class i need to make sure the class is passed a type which has SomeAttribute. So this is how i do it now:
public class Test()
{
public Test(SomeType obj)
{
if(!obj.GetType().IsDefined(typeof(SomeAttribute), false))
{
throw new ArgumentException("Errormessage");
}
}
}
But this means that i don't get any errors at compile time but somewhere at runtime, if obj does not have the attribute. Is there a way to specify in the method declaration that the parameter must have some attribute ? So i get errors i compile time when using the wrong parameters, or do i have to use an empty interface ?
There's no way to enforce an attribute at compile-time. You may want to reconsider your design - usually attributes are more about metadata, less about runtime behavior.
NDepend's Code Query Language is a static anlysis tool that could probably detect violations - but if you're not already using NDepend, I'd be hesitant to include it for this requirement alone.
Then again, lacking context of what you want to do - it's a bit like solving the other half your problem.
No, there's no way of requiring an attribute - but you could always write unit tests to scan through your assemblies and check that the appropriate attributes had been applied - assuming you can actually detect this requirement.
It sounds somewhat odd though - could you give some more details as to why you're using this scheme? Perhaps another approach would be more appropriate, such as another parameter to describe the extra data you're interested in.
Related
I'm not sure 'annotations' is the current term, I'll try to explain by example:
[MyAnnotation]
[TestMethod]
public void Test123()
{
...
}
I want to define 'MyAnnotation' to affect the method in some way. Is that possible?
Couldn't find useful information about it. Thanks.
"Annotations" (as they are called in Java) are called "Attributes" in C#.
You can easily define your own attributes. But they are not doing anything by their own. Attributes are only meta data. You need additional code to act on them. E.g. you could write a parser that detects them on runtime.
For running a test twice if it has your attribute attached, you would either need to write your own test-runner or extend the one you are currently using. Maybe there are even test-runners out there that are extensible in such a way. No matter what, nothing is going to happen at runtime, just because you attached a new attribute to a class or method.
I created a custom attribute class that will check the system security and throws an authentication exception if there is a security error.
public class EntityChecker: System.Attribute
{
public EntityChecker(int entityId)
{
// doing some logic to check if the entityId is allowed to be inserted
}
}
I want to use this custom attribute as a declaration to an entity addition function and I want to pass a variable from the function to the attribute constructor. can something like this be done?
[EntityChecker(entityId)]
public int AddNewEntity(entityId)
{
// logic of entity addition
}
Can something like this be done ?!
No. Constructor parameters in attributes must be resolved at compile time. They are intended as metadata on the type or method itself, not something that would be used per call or per instance.
Given your description, an attribute is likely not an appropriate way to handle this. Since you want to run extra code that happens per call, you will need a different technique. For example, you could pass a delegate, ie:
public int CheckedAddEntity(int entityId, Func<int, int> funcToAdd)
{
// Perform your checking on entityId here
return funcToAdd();
}
This would let you then call via something like:
int result = CheckedAddEntity(entityId, AddNewEntity);
In this case, I recommend looking at Aspect-Oriented programming. It is a different way of doing code, but one that allows you to re-use the boilerplate logic (e.g. authentication) throughout. You might have to design your attribute a little bit differently, but all of the logic can be put into an "aspect" which then gets compiled automatically into the code when you build the project.
I personally use PostSharp, although I know there are others out there. They have a free license available for development; as long as you don't require advanced functionality, it's very cost-effective.
http://www.postsharp.net/blog/post/5-Ways-That-Postsharp-Can-SOLIDify-Your-Code-Authorization
I am using PostSharp to add some compile time logic to my attributes - in once case [IndexedCategory ("CatName", CatIndex)]. The trouble comes comes in because IndexedCategory derives from CompoundAspect - which has a reasonable number of named params.
Is there any way which I can prevent these from being accessed / shown by intellisence?
Cheers
I tried a few things... one sure fire way of getting it not to compile would be to re-declare the properties as obsolete or take away the setter - not nice, though.
I tried a few other settings (non-browsable, marked immutable*), but it didn't help much:
[ImmutableObject(true)] // I'm sure this used to toggle intellisense for attribs
public class FooAttribute : BarAttribute
{
[EditorBrowsable(EditorBrowsableState.Never), Browsable(false)]
[ReadOnly(true)]
public new string Name { get { return base.Name; } }
}
Anyway, in the above Name can't be set for an attribute, even though it can on the base. Hacky and ugly.
I think you should rethink your design. I'm not sure inheritance is the way to go, maybe composition would better suite your needs. Without knowing more about what you're trying to accomplish, it's really hard to give concrete examples, but if you don't need the properties of the base class, why are you inheriting from it?
I have a class holding complex scientific computations. It is set up to only allow a user to create a properly instantiated case. To properly test the code, however, requires setting internal state variables directly, since the reference documents supply this data in their test cases. Done improperly, however, it can invalidate the state.
So I must have the ability, a member function, to set internal variables from the unit test programs. But I want to strongly discourage normal users from calling this function. (Yes, a determined user can muck with anything... but I don't want to advertise that there is a way to do something wrong.)
It would be nice to be able to tell Intellisense to not show the function, for instance.
The best solution I have at the moment is to just name the function something like: DangerousSet().
What other options do I have?
Follow-Up
I found Amy B's answer most useful to my situation. Thanks!
Mufasa's suggestion to use reflection was great, but harder to implement (for me).
Chris' suggestion of using a decorator was good, but didn't pan out.
BFree's suggestion on XML is also good, and was already in use, but doesn't really solve the problem.
Finally, BillTheLizard's suggestion that the problem is in the source documents is not something I can control. International experts publish highly technical books and journal articles for use by their community. The fact that they don't address my particular needs is a fact of life. There simply are no alternative documents.
You can use InternalsVisibleToAttribute to mark internal members as visible to your test assembly. It seems to shine when used in this context, though its not quite "friend".
Mark your DangerousSet function internal instead of public.
In Properties\AssemblyInfo.cs of the project containing DangerousSet:
[assembly:InternalsVisibleTo("YourTestAssembly")]
If you have two test assemblies for whatever reason, the syntax is:
[assembly:InternalsVisibleTo("TestAssembly1"),
InternalsVisibleTo("TestAssembly2")]
Decorate your method with this attribute:
[System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)]
This will hide it from Intellisense.
EDIT:
But apparently this has a rather significant caveat: "In Visual C#, EditorBrowsableAttribute does not suppress members from a class in the same assembly." Via MSDN.
Suppose you want to test this object by manipulating its fields.
public class ComplexCalculation
{
protected int favoriteNumber;
public int FavoriteNumber
{
get { return favoriteNumber; }
}
}
Place this object in your test assembly/namespace:
public class ComplexCalculationTest : ComplexCalculation
{
public void SetFavoriteNumber(int newFavoriteNumber)
{
this.favoriteNumber = newFavoriteNumber;
}
}
And write your test:
public void Test()
{
ComplexCalculationTest myTestObject = new ComplexCalculationTest();
myTestObject.SetFavoriteNumber(3);
ComplexCalculation myObject = myTestObject;
if (myObject.FavoriteNumber == 3)
Console.WriteLine("Win!");
}
PS: I know you said internal, but I don't think you meant internal.
It sounds like your real problem is in your reference documents. You shouldn't test cases that are impossible to encounter under proper use of your class. If users shouldn't be allowed to change the state of those variables, then neither should your tests.
You can also use reflection. Google search turned up Unit testing private methods using reflection.
Can your test code include a subclass of the calculations class? If so, you can mark the function protected and only inheritors will be able to use it. I'm pretty sure this also takes it out of intellisense, but I could be wrong about that.
What I've done in the past is I put XML Comments by the method and used the section to write in big bold letters. DON'T USE THIS METHOD or whatever. That way, if someone tried to use it, Intellisense would give them a nice warning.
Following on from my recent question on Large, Complex Objects as a Web Service Result. I have been thinking about how I can ensure all future child classes are serializable to XML.
Now, obviously I could implement the IXmlSerializable interface and then chuck a reader/writer to it but I would like to avoid that since it then means I need to instantiate a reader/writer whenever I want to do it, and 99.99% of the time I am going to be working with a string so I may just write my own.
However, to serialize to XML, I am simply decorating the class and its members with the Xml??? attributes ( XmlRoot , XmlElement etc.) and then passing it to the XmlSerializer and a StringWriter to get the string. Which is all good. I intend to put the method to return the string into a generic utility method so I don't need to worry about type etc.
The this that concerns me is this: If I do not decorate the class(es) with the required attributes an error is not thrown until run time.
Is there any way to enforce attribute decoration? Can this be done with FxCop? (I have not used FxCop yet)
UPDATE:
Sorry for the delay in getting this close off guys, lots to do!
Definitely like the idea of using reflection to do it in a test case rather than resorting to FxCop (like to keep everything together).. Fredrik Kalseth's answer was fantastic, thanks for including the code as it probably would have taken me a bit of digging to figure out how to do it myself!
+1 to the other guys for similar suggestions :)
I'd write a unit/integration test that verifies that any class matching some given criteria (ie subclassing X) is decorated appropriately. If you set up your build to run with tests, you can have the build fail when this test fails.
UPDATE: You said, "Looks like I will just have to roll my sleeves up and make sure that the unit tests are collectively maintained" - you don't have to. Just write a general test class that uses reflection to find all classes that needs to be asserted. Something like this:
[TestClass]
public class When_type_inherits_MyObject
{
private readonly List<Type> _types = new List<Type>();
public When_type_inherits_MyObject()
{
// lets find all types that inherit from MyObject, directly or indirectly
foreach(Type type in typeof(MyObject).Assembly.GetTypes())
{
if(type.IsClass && typeof(MyObject).IsAssignableFrom(type))
{
_types.Add(type);
}
}
}
[TestMethod]
public void Properties_have_XmlElement_attribute
{
foreach(Type type in _types)
{
foreach(PropertyInfo property in type.GetProperties())
{
object[] attribs = property.GetCustomAttributes(typeof(XmlElementAttribute), false);
Assert.IsTrue(attribs.Count > 0, "Missing XmlElementAttribute on property " + property.Name + " in type " + type.FullName);
}
}
}
}
You can write unit tests to check for this kind of thing - it basically uses reflection.
Given the fact this is possible I guess it would also be possible to write a FxCop rule, but I've never done such a thing.
You can write an FxCop rule or even check for the attributes by calling GetType() in the base class's constructor and reflecting over the returned type.
A good FXCop rule (and one which I am finding I need right now) would be to check that all objects that are being added to the ASP.NET Session have the Serializable attribute. I'm trying to move from InProc session state to SQL Server. First time I requested a page, my site blew up on me because non-serializable objects were being stored in Session. Then came the task of hunting through all the source code looking for every instance where an object is set in the Session... FXCop would be a nice solution. Something to work on...
You can also use this concept/post-processor to enforce relationships between attributes and use similar login to enforce relationships between classes and attributes at compile time:
http://www.st.informatik.tu-darmstadt.de/database/publications/data/cepa-mezini-gpce04.pdf?id=92