perhaps class is by design static scoping and scriptblock with validateScript is interpreted dynamically...maybe you can create your own attribute with class [System.Management.Automation.ValidateArgumentsAttribute]

In this specific case you could use [ValidateRange(0, 10)] or [ValidateRange([int]::MinValue, 10)] depending on your needs.

But yeah, classes are handled at parse time, so attributes have some extra restrictions. I'm not sure there's a way around that? Might be, but I would guess there probably isn't much that's really doable there.

@vexx32 The simple example is just that - a simple example. My need for ValidateScript is obviously much more complex.

Could you point me to the documentation where this is listed as expected behavior since you are not surprised about this behavior?

I could not find many relevant matches doing a web search about validatescript and class but several did have other people wondering about ValidateScript and this problem. So it would not seem to be very well documented.

It is disappointing. If class methods are not static like this then I might be able to figure out an ugly workaround if I have to.

I'm mainly not surprised because I've seen it before, both in PS and (more importantly) in C# itself. In compiled code you can't have non-constant/non-primitive values for attributes. It's actually part of the attribute language specification which states:

The types of positional and named parameters for an attribute class are limited to the attribute parameter types, which are:

• One of the following types: bool, byte, char, double, float, int, long, sbyte, short, string, uint, ulong, ushort.
• The type object.
• The type System.Type.
• An enum type, provided it has public accessibility and the types in which it is nested (if any) also have public accessibility (Attribute specification).
• Single-dimensional arrays of the above types.

A constructor argument or public field which does not have one of these types, cannot be used as a positional or named parameter in an attribute specification.

I think there are similar underlying requirements for dynamically compiled assemblies, and .NET in the more general case as well. I'm pretty sure the only reason [ValidateScript()] is even a thing is because PowerShell script can do more or less whatever it want, as long as it's willing to handle things on its own. [ValidateScript()] is possible in PS probably because PS isn't directly compiling functions, it's doing it piecemeal and can handle attributes however differently it wants, more or less. Attribute classes are free to have whatever properties they want, but they can only use the above types in their constructor parameters when they're decorating a class and need to be resolved at compile time.

Classes in PS are a different story entirely, and have to be compiled as-is at parse time, meaning there's no deferred compilation or special handling of attributes for the most part, they just behave very much like C# / .NET attributes.

As far as documenting it in PowerShell, I'd tend to agree that it should be mentioned somewhere in the classes documentation.

/cc @rjmholt

Yeah @vexx32 has hit it on the head. It looks like we should handle this more gracefully.

I imagine that this is "expected if you think about the implementation and extrapolate", but has not been anticipated by the existing implementation.

Currently classes are compiled into dynamic .NET assemblies, and won't tolerate attributes that do something that .NET doesn't like, namely use values that can't be embedded into .NET static metadata.

I don't see ValidateScript ever working as an attribute for classes, but I also don't see that as a big issue since classes don't need to do parameter binding. Instead the validation can be done in the method body (similar to how it would be done for a C# method).

I think we should:

• Emit a parse-time semantic error when this attribute is used on a class method
• Update documentation to explicitly document how attributes work with classes