We Keep Coding

Prevent certain classes to call certain methods using Attributes

I plan to give method calling privileges to certain classes in my program using Attributes but I just have no clude how to.
For example, here is what I want my Customer class to look like:
[ForbiddenMethodsAttr(listOfMyForbiddenMethods)]
public class Customer
{
public Customer { }
}
And if I want to call a given function, the intellisense should warm me that I can't, The reason I want to do this is because calling those functions may cause some issues and not I'm the only one who will code this project but some friends as well. So if it is possible to write such an attribute, how to do it?

You could mark the methods as obsolete and then anyone calling them will get a compiler warning (though not error). Its not elegant, but neither is attempting to restrict method calls without using scoping conventions.

Safeguard code from changes made by other programmers

In C# I have a class that is using a function to do some work. The thing is: this function needs the class to a have a specific structure in order for it to return correct results (for "specific structure" you can imagine the class using a specific set of enumeratives that the function relies on as well).
My question is: what is the best way to try and safeproof my function from future changes to the structure of the using class? Or at least have it so that if another programmer changes the class' structure my function will notify him that changes to the function itself are needed in order for everything to work correctly.
I hope everything is clear.
Thanks in advance!

+1 for unit tests as #joews suggested
If you cannot / don't want to use them, a very rough way to deal with this:
In the first line of Main, call a method CheckMyClass()
void CheckMyClass()
{
#if DEBUG
bool theClassIsOK = ...//check your class is still how it should be.
if (! theClassIsOK)
throw new ApplicationException ("something changed TheClass in a wrong way, DiG knows what's wrong with this");
#endif
}
Not elegant at all, I know.
Replace "DiG knows" with something more useful for your collegues (or ex collegues, since they will modify the class the day after you found a new job...)

The best way to make sure your function gets the dependencies it needs is to pass them in explicitly as arguments. So don't require an instance of the class as an argument, but rather each of the enumerations or other class members.
You could also consider making the class implement an interface with all the required attributes. If you distribute the interface along with your function in an assembly, people won't be able to change it.
Finally, you could put assertions into your function and return exceptions if the assertions aren't true.

C#: Making sure parameter has attribute

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.

Hiding a function

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.

Enforce Attribute Decoration of Classes/Methods

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