What's the point of indicating AllowMultiple=false on an abstract Attribute class?

On a recent question about MVC attributes, someone asked whether using HttpPost and HttpDelete attributes on an action method would result in either request type being allowed or no requests being allowed (since it can't be both a Post and a Delete at the same time). I noticed that ActionMethodSelectorAttribute, from wh开发者_StackOverflowich HttpPostAttribute and HttpDeleteAttribute both derive is decorated with

[AttributeUsage(AttributeTargets.Method,
                AllowMultiple = false,
                Inherited = true)]

I had expected it to not allow both HttpPost and HttpDelete on the same method because of this, but the compiler doesn't complain. My limited testing tells me that the attribute usage on the base class is simply ignored. AllowMultiple seemingly only disallows two of the same attribute from being applied to a method/class and doesn't seem to consider whether those attributes derive from the same class which is configured to not allow multiples. Moreover, the attribute usage on the base class doesn't even preclude your from changing the attribute usage on a derived class. That being the case, what's the point of even setting the values on the base attribute class? Is it just advisory or am I missing something fundamental in how they work?

FYI - it turns out that using both basically precludes that method from ever being considered. The attributes are evaluated independently and one of them will always indicate that the method is not valid for the request since it can't simultaneously be both a Post and a Delete.

Setting AllowMultiple on a base attribute essentially sets a default for all attributes that derive from it. If you wanted all attributes deriving from a base atribute to allow multiple instances then you can save duplication by applying an [AttributeUsage] attribute to this effect to the base attribute avoiding the need to do the same to all the derived attributes.

For example, suppose you wanted to allow this:

public abstract class MyAttributeBase : Attribute
{
}

public sealed class FooAttribute : MyAttributeBase
{
}

public sealed class BarAttribute : MyAttributeBase
{
}

[Foo]
[Foo]
[Bar]
[Bar]
public class A
{
}

As it stands, this generates a compiler error since custom attributes, by default, do not permit multiple instances. Now, you could apply an [AttribteUsage] to both [Foo] and [Bar] like this:

[AttributeUsage(AttributeTargets.Class, AllowMultiple = true)]
public sealed class FooAttribute : MyAttributeBase
{
}

[AttributeUsage(AttributeTargets.Class, AllowMultiple = true)]
public sealed class BarAttribute : MyAttributeBase
{
}

But alternatively, you could instead just apply it to the base attribute:

[AttributeUsage(AttributeTargets.Class, AllowMultiple = true)]
public abstract class MyAttributeBase : Attribute
{
}

public sealed class FooAttribute : MyAttributeBase
{
}

public sealed class BarAttribute : MyAttributeBase
{
}

Both approaches have the same direct effect (multiple instances of both [Foo] and [Bar] are permitted) but the second approach also has the indirect effect that any other attributes deriving from [MyAttribute] will now allow multiple instances unless they have their own [AttributeUsage] that overrides that setting.

AllowMultiple allows/disallows that specific attribute being used more than once. It has no effect on whether other attributes can be combined with it.

So for example, if you have an ObfuscationAttribute that controls whether renaming of the method is enabled or disabled, you would not want users to be able to do this:

[Obfuscation("DisableRenaming")]
[Obfuscation("EnableRenaming")]
void MyMethod()
{
}

In this case Obfuscation cannot be both enabled and disabled, so you'd use AllowMultiple=false to ensure that the method is only marked once with this particular attribute.

What you could hypothetically do, in your mutually-exclusive case, is use a single attribute called HttpSettings, which took a paraneter indicating whether it applied to the Post or Delete "mode". This could then be AllowMultiple=false to enforce the mutual exclusivity of the options.

Let's make a short test:

using System;
using System.Text;
using System.Collections.Generic;
using System.Linq;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using System.Reflection;

namespace TestAttrs {
    public abstract class BaseAttribute : Attribute { 
        public string text; 
    }

    [AttributeUsage(AttributeTargets.Method, AllowMultiple = true, Inherited = true)]
    public class MultipleInheritedAttribute : BaseAttribute {  }

    [AttributeUsage(AttributeTargets.Method, AllowMultiple = true, Inherited = false)]
    public class MultipleNonInheritedAttribute : BaseAttribute {  }

    [AttributeUsage(AttributeTargets.Method, AllowMultiple = false, Inherited = true)]
    public class SingleInheritedAttribute : BaseAttribute {  }

    [AttributeUsage(AttributeTargets.Method, AllowMultiple = false, Inherited = false)]
    public class SingleNonInheritedAttribute : BaseAttribute {  }

    public class BaseClass {
        [MultipleInherited(text = "MultipleInheritedBase")]
        [MultipleNonInherited(text = "MultipleNonInheritedBase")]
        [SingleInherited(text = "SingleInheritedBase")]
        [SingleNonInherited(text = "SingleNonInheritedBase")]
        public virtual void Method() { ; }
    }

    public class DerivedClass : BaseClass {
        [MultipleInherited(text = "MultipleInheritedDerived")]
        [MultipleNonInherited(text = "MultipleNonInheritedDerived")]
        [SingleInherited(text = "SingleInheritedDerived")]
        [SingleNonInherited(text = "SingleNonInheritedDerived")]
        public override void Method() {
            base.Method();
        }
    }

    [TestClass]
    public class AttributesTest {
        [TestMethod]
        public void TestAttributes() {
            MemberInfo mi = typeof(DerivedClass).GetMember("Method")[0];
            object[] attrs = mi.GetCustomAttributes(true);

            string log = "";
            foreach(BaseAttribute attr in attrs) {
                log += attr.text+"|";
            }
            Assert.AreEqual("MultipleInheritedDerived|SingleInheritedDerived|SingleNonInheritedDerived|MultipleNonInheritedDerived|MultipleInheritedBase|", log);
        }
    }
}

As you can see, if attribute is marked Inherted=true then it will be returned for derived classes, but if inherited method is marked with the same attribute - it will be supressed if AllowMultiple=false. So - in our test, log string contains both "MultipleInheritedDerived" and "MultipleInheritedBase", but not "SingleInheritedBase".

So answering your question - what's a point? This combination allows you to have a base controller with virtual method that you can override wihout worrying about attribute (it will be taken from base method), but at the same time to be able to override it if you want. HttpPostAttribute is not a good example, because it has no parameters, but other attributes can benefit from such settings.

Also, please note that code consuming attributes:

       object[] attrs = mi.GetCustomAttributes(true);

specifies that it is interested in inherited attributes. If write

       object[] attrs = mi.GetCustomAttributes(false);

then result would contain 4 attributes regardless of their usage settings. So it is possible for developer to ignore Inherited attribute usage setting.