Note that this is technically a breaking change

What is something that would break with this change?

From the issue, users with a component named TestÄh currently need to use a tag with <vc:testäa>, but after the change they would need to use <vc:test-äa>. Until they make the change in their source, they'd lose the functionality of the view component and the tag would simply be rendered to Html and presumably ignored by the browser.

As David says. Plus this also affects normal TagHelpers (not just ViewComponent tag helpers) - if users don't specify the HtmlTargetElement explicitly, it's derived from the TagHelper class name in the same fashion. (I will add tests.)

@chsienki, @jaredpar, @DustinCampbell, @danroth27 for their thoughts. I'm inclined to won't fix this bug; it's been around for a very long time, and we don't have a good way of communicating the change to users in the form of compilation errors. It's also another case where runtime compilation would probably produce different results, and there'd be no way to get equivalent behavior between runtime and non-runtime compilation.

We could also tie the breaking change to RazorLangVersion. But I agree it does not seem worth it.

I'm supportive of not making this change given the breaking change impact.

Hi, wouldn't it be possible to generate tag helpers with both the correct name and the current incorrect name? This would correct the bug while preserving backwards compatibility for those that rely on the current tag names.

Yes, I think that would work, but at the cost of more complexity in the implementation.

The problem my team is currently having is that the generated tag helpers for view components are incorrectly named for our Swedish domain specific words, so we need to either contort our view components names or manually write our own tag helpers (because HtmlTargetElement doesn't work on view components).

It's manageable but it's unnecessary friction and surprising when it doesn't work as it's supposed to.

Let me reopen the original issue with this alternative so it will get triaged again.

@DavidZidar Instead of using View Components, could you use Blazor components with the Component Tag Helper instead? If not, what would be needed to enable you to do so? Ideally, we'd like to align ASP.NET Core on a single component model.

@danroth27 We have a fairly large application that is built on top of Optimizely CMS where all the Optimizely Blocks are view components (because Optimizely requires this), so we use view components for non-block components as well to be able to reuse a lot of common code. I may be wrong but I don't think HTML helpers and tag helpers work in Blazor components?

Also, we have a couple of filters that need to wrap view components (to perform error handling and authorization policies and so on) so I had to find a way to make that work with view components because that is not something that is supported by ASP.NET by default. Can this be done with Blazor components? This is not something that I have investigated.

I may be wrong but I don't think HTML helpers and tag helpers work in Blazor components?

That's correct.

Also, we have a couple of filters that need to wrap view components (to perform error handling and authorization policies and so on) so I had to find a way to make that work with view components because that is not something that is supported by ASP.NET by default. Can this be done with Blazor components?

Nope, this also isn't something we currently support.

Thanks for sharing these additional details!