When you put a [Parameter] on a component, and then invoke it with <MyComponent param=@someValue>, it doesn't do static type checking at compile-time to make sure that value will actually work. All of the necessary information to do so is present, but no type-checking is done until runtime, when it attempts to set the parameter value through Reflection, making it possible for this to blow up with an InvalidCastException.
This should not be the case.
This should be added to aspnet/AspNetCore#5455
Good suggestion.
@rynowak The implementation that occurs to me would be changing the AddAttribute codegen to insert a cast to whatever the target parameter type is. I'm hoping the compiler is smart enough not to emit a cast instruction if it knows statically that the supplied value is derived from the target parameter type. But even if not the perf overhead is probably not detectable.
Alternatively we could create an AddAttribute<T> that requires you to pass a T, but that might make our current overload selection mechanism quite difficult to reason about.
What do you think?
This seems pretty straightforward. We'll want to try both and choose based on which provides the better error message.
Inserting a cast sounds dangerous though as this would possibly invoke custom explicit operators and would allow to assign a decimal to an int for example.
Adding a thunk that the generated code calls through is pretty straightforward, and seems to fix the problem pretty nicely. We don't have super fine-grained control over what the error message looks like, but I think it's actually pretty decent.

Implemented in 4dee648ab8b3f5b350f3587c5748faee372224ac
Most helpful comment
Adding a thunk that the generated code calls through is pretty straightforward, and seems to fix the problem pretty nicely. We don't have super fine-grained control over what the error message looks like, but I think it's actually pretty decent.