aspnetcore: [8.0.100-preview.5.23276.4]Unable to cast object of type when passing data(custom type) to a component in Blazor Apps after building

This does tie in with a broader class of requests we’ve had for a “strict parameter passing” mode where you can only pass declared parameters to a component. I could imagine that such a mode would also impose the limit that everything you pass has to be named exactly (case sensitively).

One related issue is https://github.com/dotnet/aspnetcore/issues/45667 - I’m sure there was another one that went into more detail but can’t find it now.

The concept for doing this nonbreakingly is that people would opt in on a per-component or per-project level (e.g., in _Imports.razor). Then it could be enforced at compile time, at least when using any components that don’t have CaptureUnmatchedAttributes. It doesn’t really work for ones that do use CaptureUnmatchedAttributes because of the forward-compat issue mentioned above - people would be unable to add any new parameters without risking a breaking change.

It’s not very .NET-y.

No, but it is very HTML-y, and we’re dealing with a syntax that you can equally think of as being HTML-like as it is C#-like. There isn’t really an objectively right choice for this.

In one sense I wish we had sided with the stricter rule in the beginning, but there are arguments against it. Part of our original rationale was being able to override standard HTML attributes nonbreakingly. For example consider QuickGrid, which has a parameter Class. If it didn’t originally have Class but did support passthrough of arbitrary HTML attributes, people may have been writing <QuickGrid class="my-css-class">. Then later, we want to add a “class” parameter so we can do programmatic stuff with it. Would we call it Class or class? The latter would preserve back-compat, but is also completely inconsistent with our style rules. And some people might already have been writing Class (or to make an absurd but technically valid argument, even cLaSs) since that’s legal in HTML. Being case-insensitive solves all of that.

What do you think about making the runtime more strict by default and then providing a back compat switch for anyone that needs it?

Even if we can get over the design problem mentiond above, I am nervous about the extent of the breaking change that would cause.

Good breaking changes are ones where affected code is immediately obvious and can be detected by the compiler. This is at the opposite extreme, since nonmatching parameters would start going into CaptureUnmatchedAttributes, changing the behavior of components in subtle ways instead of failing at compile time or even giving a clear runtime exception. People affected by this would have almost no way to know why their app was now broken, so it would be very hard to know they should look for a compat flag.

@SteveSandersonMS @danroth27 Ugh, apologies GitHub notifications failed me here and I didn’t see your responses.

I like the idea of the generic AddComponentParameter call, but I can’t remember right now if the compiler actually has access to the expected component type at the point where we emit this call.

If we do, we could presumably just insert a cast to the target type in the AddAttribute version. Given that we didn’t do that it makes me think we might not. @jjonescz do you know if we have that info at the point we emit these calls?

If we don’t, then I don’t think we can easily fix this: we have to decide to either allow implicit casting or we don’t. Given that we know it causes reported issues I would lean on the side of keeping the new behavior and noting breaking change, but lets see if we can do the target typing version before deciding on it.

@mkArtakMSFT @danroth27 @jaredpar @jjonescz

This is caused by the following change: https://github.com/dotnet/razor/pull/8286, which comes from https://github.com/dotnet/aspnetcore/pull/46562

Previously, having an implicit cast to e.g. string on an object component parameter could cause the wrong AddAttribute overload to be chosen for component params, which later caused type errors when the thing was looked up and found to be a string rather than the expected object type.

We fixed this by calling the new AddComponentParameter(...) method, or adding an (object) cast if the runtime doesn’t have the new method, forcing the correct overload to be called.

In this case here we’re hitting the (object) version of the code gen: the object in question was castable to string so we previously chose the string overload of AddAttribute. Because the underlying object on the parameter is actually a string, it doesn’t have the issue at runtime, because the types match, and the application functioned correctly.

In the new code gen we cast the underlying object directly to object so it never undergoes the explicit string conversion. When we then try and assign that to a string field at runtime it fails.

I think it’s fair to say that the previously observed behavior worked unintentionally, and we’ve ‘fixed’ it with that PR, but I’m not sure how many other cases of this are in the wild and if we want to try and think about how we can maintain the existing behavior. Note that even though the code path will be different on a runtime with AddComponentParameter the outcome will be the same.

For reference:

Previous code:

        __builder.AddAttribute(108, "DateFormat", RuntimeHelpers.TypeCheck<string>("{0:MM/dd}"));
        __builder.AddAttribute(109, "PlaceHolder", (string) (MetaStoreProperty<string>) this.S.ExpirationPlaceholderCaption);
        __builder.AddAttribute(110, "Value", (object) RuntimeHelpers.TypeCheck<DateTime?>(this.expDate));
        __builder.AddAttribute<DateTime?>(111, "ValueChanged", RuntimeHelpers.TypeCheck<EventCallback<DateTime?>>(EventCallback.Factory.Create<DateTime?>((object) this, RuntimeHelpers.CreateInferredEventCallback<DateTime?>((object) this, (Action<DateTime?>) (__value => this.expDate = __value), this.expDate))));
        __builder.AddAttribute(112, "ValueExpression", (object) RuntimeHelpers.TypeCheck<Expression<Func<DateTime?>>>((Expression<Func<DateTime?>>) (() => this.expDate)));

New code:

        __builder.AddAttribute(108, "DateFormat", (object) RuntimeHelpers.TypeCheck<string>("{0:MM/dd}"));
        __builder.AddAttribute(109, "PlaceHolder", (object) this.S.ExpirationPlaceholderCaption);
        __builder.AddAttribute(110, "Value", (object) RuntimeHelpers.TypeCheck<DateTime?>(this.expDate));
        __builder.AddAttribute(111, "ValueChanged", (object) RuntimeHelpers.TypeCheck<EventCallback<DateTime?>>(EventCallback.Factory.Create<DateTime?>((object) this, RuntimeHelpers.CreateInferredEventCallback<DateTime?>((object) this, (Action<DateTime?>) (__value => this.expDate = __value), this.expDate))));
        __builder.AddAttribute(112, "ValueExpression", (object) RuntimeHelpers.TypeCheck<Expression<Func<DateTime?>>>((Expression<Func<DateTime?>>) (() => this.expDate)));

@mkArtakMSFT @danroth27 Not sure of anything that intentionally changed here. I’ll take a look.

Can we get more details on the type of ExpirationPlaceholderCaption? How was that property getting cast to a string previously? Can we see the type?