Improve partial class support in Blazor #14646
Assignees
Labels
Milestone
Comments
pranavkm
added
enhancement
NTaylorMullen
added a commit
to dotnet/razor
that referenced
this issue
Oct 10, 2019
- 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. dotnet/aspnetcore#14646
NTaylorMullen
added a commit
to dotnet/razor
that referenced
this issue
Oct 14, 2019
- 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. dotnet/aspnetcore#14646
NTaylorMullen
added a commit
to dotnet/razor
that referenced
this issue
Oct 15, 2019
- 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. - Our IComponent detection logic has to be "fuzzy" because we don't have access to the C# compilation at the workspace change detection layer. Therefore we need to look at type names and do string comparisons vs. looking up specific types in the compilation. - Added several tests to ensure we enqueue and that we properly detect component classes. dotnet/aspnetcore#14646
NTaylorMullen
added a commit
to dotnet/razor
that referenced
this issue
Oct 15, 2019
- 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. - Our IComponent detection logic has to be "fuzzy" because we don't have access to the C# compilation at the workspace change detection layer. Therefore we need to look at type names and do string comparisons vs. looking up specific types in the compilation. - Added several tests to ensure we enqueue and that we properly detect component classes. dotnet/aspnetcore#14646
NTaylorMullen
added a commit
to dotnet/razor
that referenced
this issue
Oct 15, 2019
- 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. - Our IComponent detection logic has to be "fuzzy" because we don't have access to the C# compilation at the workspace change detection layer. Therefore we need to look at type names and do string comparisons vs. looking up specific types in the compilation. - Added several tests to ensure we enqueue and that we properly detect component classes. dotnet/aspnetcore#14646
NTaylorMullen
added a commit
to dotnet/razor
that referenced
this issue
Oct 16, 2019
- 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. dotnet/aspnetcore#14646
NTaylorMullen
added a commit
to dotnet/razor
that referenced
this issue
Oct 16, 2019
- 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. dotnet/aspnetcore#14646
NTaylorMullen
added a commit
to dotnet/razor
that referenced
this issue
Oct 16, 2019
- 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. dotnet/aspnetcore#14646
|
Does this cover inheriting from a generic base class? Last I tried code like below resulted in compiler errors. If I put everything in the .razor file and don't use partial classes it compiles fine. ` |
|
Works for me so I'd say yes it works 😄
|
|
👍 |
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Follow up to #5487
[ ] Remove support forcan't do this until VSCode partial class support has been addedMangleClassName(Add Blazor partial class support in Visual Studio. razor#1182 (comment))[ ] Target the support based on Razor version (Add Blazor partial class support in Visual Studio. razor#1182 (comment))Decided against thisThe text was updated successfully, but these errors were encountered: