- The Blazor runtime doesn't support adding attributes prior to any sort of content frames being applied. This change ensures that `ComponentAttributes` (how preventDefault / stopPropagation are represented) are handled like other HTML attributes (applied first).
- Updated existing tests and their baselines.
aspnet/AspNetCoredotnet/aspnetcore-tooling#16611
\n\nCommit migrated from 1513cd2a5b
- We now do aggressive detection on the type of C# class that's being edited. In order to not impact C# scenarios we only do work if C# assets are available to us. Meaning, we inspect the old document and if that document has its' semantic model available we spend cycles to determine if it's a component. In the case that we find a C# component class that wasn't previously caught we enqueue an update.
- Added several tests to ensure we enqueue and that we properly detect component classes.
aspnet/AspNetCoredotnet/aspnetcore-tooling#14646
\n\nCommit migrated from d8b62e121f
- The 3.0 SDK adds RazorDeclaration files to the compile list if they exist. If a user builds in VS and then does a project level operation (adding a property group or item group to their project file) a design time build will trigger for unrelated reasons and declaration files will be included as part of the C# compilation resulting in duplicate member errors. This change ensures that even if declaration files are added we then remove them to ensure we avoid those declaration additions.
- One unfortunate aspect of this change is that declarations are added to the compile list for a brief moment resulting in errors and then are instantly removed in some situations. I say "some situations" because when this happens it is highly dependent on how / when the project system decides to perform a design time build.
aspnet/AspNetCoredotnet/aspnetcore-tooling#14646
\n\nCommit migrated from b64c9317c4
Fixes aspnet/AspNetCoredotnet/aspnetcore-tooling#13181
The big change here is that we have to allow an HtmlAttributeIRNode to have
a dynamically computed attribute name. This isn't something that exists
anywhere else in the system.
\n\nCommit migrated from 559f0f5e52
This change updates tag helper binding logic to allow directive
attributes (when they appear alone) to bind to any kind of tag
(start/end, void, self-closing).
Tag Helpers don't have a semantic that allows this level of flexibility
- using StartTagOnly as suggested in the issue means that this would
*only* work for void elements.
There's no change to any of the directive attribute implementations
because this is a global change in the tag helper infra.
\n\nCommit migrated from fd72afc1c6
- No longer mark declaration files as single file generators. Prior to this we relied on SingleFileGenerators to dynamically update the declaration files when .razor files changed. However, to make partial classes work we can no longer depend on declaration files being available because their existence causes us to have to mangle class names for opened documents; otherwise you get two files with same name and result in ambiguous definition errors.
- Stopped including declaration files as part of the users compilation. This was intended to make the design time experience operate more similar to how Blazor apps function at runtime (directly access each component instead of their declarations). We now rely on the background code generation effort built from the find all references work to supply users with strongly typed component names.
- Stop mangling class names for Visual Studio. Razor.VSCode has its own set of configurations which i'm not addressing as part of this changeset.
- Start generating components with the partial modifier to their class name to enable partial class support.
- Updated existing tests to expect partial modifier.
aspnet/AspNetCoredotnet/aspnetcore-tooling#5487\n\nCommit migrated from 73858cdd37
- No longer mark declaration files as single file generators. Prior to this we relied on SingleFileGenerators to dynamically update the declaration files when .razor files changed. However, to make partial classes work we can no longer depend on declaration files being available because their existence causes us to have to mangle class names for opened documents; otherwise you get two files with same name and result in ambiguous definition errors.
- Stopped including declaration files as part of the users compilation. This was intended to make the design time experience operate more similar to how Blazor apps function at runtime (directly access each component instead of their declarations). We now rely on the background code generation effort built from the find all references work to supply users with strongly typed component names.
- Stop mangling class names for Visual Studio. Razor.VSCode has its own set of configurations which i'm not addressing as part of this changeset.
- Start generating components with the partial modifier to their class name to enable partial class support.
- Updated existing tests to expect partial modifier.
aspnet/AspNetCoredotnet/aspnetcore-tooling#5487\n\nCommit migrated from ecb3b1bdf0
Kevin Pilch
Ryan Brandenburg
William Godbe
Ajay Bhargav Baaskaran
dotnet-maestro[bot]
Brennan
Pranav K
N. Taylor Mullen
Doug Bunting
Ryan Nowak