In order to use attributes properly, some "reflection" is required, e.g:

var attrs = GetType()
                .GetMethods(System.Reflection.BindingFlags.Public | System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Instance)
                .Select(m => m.GetCustomAttributes(typeof(CustomAttribute), false).FirstOrDefault() as CustomAttribute)​

But plugins using reflection are not allowed to be published here. ("No System.Reflection usage")

Could an exception be allowed for this? - Or if not, could you add an extension method to get the Attributes of a (/the own) plugin (methods, subclasses etc.)?

I'm not sure what attributes you mean, but if there's something you want exposed you can request it to be so.

I mean custom attributes in general - because reflection is disallowed, one can't really use them.

One example I'm using attributes for currently:

[Command("example")]
[CommandInfo("does some example stuff")]
void CommandExample(...){
    ...
}​

void CommandHelp(...){
    //Generate a list of commands based on the CommandInfo Attributes
    ...
}

This way, I don't have to keep a seperate list of commands.

Another example:

private Dictionary<MethodInfo, EventRoutineAttribute> EventRoutines { get; set; }

void Init() {
    ...
    EventRoutines = GetMethodsWithAttribute<EventRoutineAttribute>();
}

[EventRoutine("example")]
private bool Example(...) {...}

private void ExampleHook(...){
    foreach (var registeredRoutine in EventRoutines) {
        //do some stuff
        registeredRoutine.Key.Invoke(this, new[] { ... })
    }
}

I'm using attributes to register behaviours for later use so I don't have to bloat my Init() method.

I could show you the complete plugin if needed, but I think you understand what I mean.

Maybe change the rules to "reflection over the own plugin (using e.g. GetType() as entry point) is okay" - I get that this is a valid security concern, but breaking your own plugin.. well is the problem of the author then, I guess?  :D

I don't think there is a way to really whitelist reflection "in your own plugin", as your plugin can still access the filesystem and cause issues for those not wanting plugins to have access to random locations. Reflection in general is there to brute force your way around restrictions.

As far as the suggested attributes go, uMod (not Oxide) will be providing a few similar to those, but I'll check with Calytic regarding custom ones.

Adding some custom attribute resolvers (outside of reflection) would be good.

Maybe some wrappers to access / execute the methods associated with the attributes would be great too