Support reloadable cshtml #35017
Support reloadable cshtml #35017
Conversation
src/Mvc/Mvc.Razor/src/ApplicationParts/RazorCompiledItemFeatureProvider.cs
Show resolved
Hide resolved
src/Mvc/Mvc.Razor/src/ApplicationParts/RazorCompiledItemFeatureProvider.cs
Outdated
Show resolved
Hide resolved
mkArtakMSFT
added
the
area-mvc
pranavkm
force-pushed
the
prkrishn/reloadable-type
branch
from
f5a3e5d to
48f3ddc
Compare
| foreach (var type in types) | ||
| { | ||
| // The Razor file has a [RazorCompiledItemMetadata("Identifier", "/Index.cshtml")]. We'll look it up. | ||
| var metadataAttribute = type.GetCustomAttributes<RazorCompiledItemMetadataAttribute>() |
There was a problem hiding this comment.
Turns out there was already a type-level attribute in Razor.Hosting that we could use. It's slightly stringly typed (you have to look up an attribute by name), but we already do this when looking up routing metadata in Razor Pages.
| ITagHelperFactory tagHelperFactory, | ||
| IViewCompilerProvider viewCompilerProvider, | ||
| ITagHelperComponentPropertyActivator tagHelperComponentPropertyActivator, | ||
| ApplicationPartManager applicationPartManager) |
There was a problem hiding this comment.
Do we need to do anything for page action descriptors? (I imagine at some point the endpoints need to be recalculated)
There was a problem hiding this comment.
The CompiledPageActionDescriptorProvider uses the ApplicationPart feature to get the set of Razor Pages - https://github.com/dotnet/aspnetcore/blob/main/src/Mvc/Mvc.RazorPages/src/Infrastructure/CompiledPageActionDescriptorProvider.cs#L56-L61. It's a fairly similar code path to how the RazorViewEngine calculates it's inputs. We update that as part of this type, and poke the IActionDescriptorChangeProvider as part of HotReloadService, so it causes Razor Pages and it's routing to be rediscovered.
It might be worthwhile to create a fake provider and simulate this e2e given how many moving parts there are to this. I'd be happy to do that in a follow up (just getting the runtime changes in since it's a major hassle to sync across dotnet/aspnetcore, dotnet/sdk, and dotnet/roslyn to test these changes out)
javiercn
left a comment
javiercn
left a comment
There was a problem hiding this comment.
Couple of small questions, but other than that looks great!
ghost
added this to the
As part of #35017, I had consolidated the DefaultViewCompiler and DefaultViewCompilerProvider types, largely as a clean up. The type DefaultViewCompilerProvider is looked up by the RuntimeCompilation package by name, and when making this change, this code was also updated. However, we've had two reports so far of users trying to use an 5.0 or earlier version of the runtime compilation package with a 6.0 app. In this case, the lookup fails and the runtime compilation feature doesn't work as expected after this. Fixes #35267
As part of #35017, I had consolidated the DefaultViewCompiler and DefaultViewCompilerProvider types, largely as a clean up. The type DefaultViewCompilerProvider is looked up by the RuntimeCompilation package by name, and when making this change, this code was also updated. However, we've had two reports so far of users trying to use an 5.0 or earlier version of the runtime compilation package with a 6.0 app. In this case, the lookup fails and the runtime compilation feature doesn't work as expected after this. Fixes #35267
#37035) As part of #35017, I had consolidated the DefaultViewCompiler and DefaultViewCompilerProvider types, largely as a clean up. The type DefaultViewCompilerProvider is looked up by the RuntimeCompilation package by name, and when making this change, this code was also updated. However, we've had two reports so far of users trying to use an 5.0 or earlier version of the runtime compilation package with a 6.0 app. In this case, the lookup fails and the runtime compilation feature doesn't work as expected after this. Fixes #35267
#37037) As part of #35017, I had consolidated the DefaultViewCompiler and DefaultViewCompilerProvider types, largely as a clean up. The type DefaultViewCompilerProvider is looked up by the RuntimeCompilation package by name, and when making this change, this code was also updated. However, we've had two reports so far of users trying to use an 5.0 or earlier version of the runtime compilation package with a 6.0 app. In this case, the lookup fails and the runtime compilation feature doesn't work as expected after this. Fixes #35267
CreateNewOnMetadataUpdateAttributewhen targeting RazorLangVersion = 6.0Fixes #34248