This change introduces ControllerContext for inside of Controllers, and
controller-specific extensibility points. ControllerContext carries with
it the model binding infrastructure needed to do all of the things that
controllers need to do.
Your version of this script opens/creates registry path "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\4.0.30319.0\AutoGenKeys\$sid"
I think the correct path should be "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0\AutoGenKeys\$sid"
- Removed `WriteTagHelperAsync` methods from `RazorPage`.
- Moved `WriteTagHelperAsync` tests into Razor since `TagHelperOutput` is now an `IHtmlContent`.
- Updated code generation test files.
aspnet/Razor#358
- This allows users to write `TagHelperOutput` directly to an `IHtmlContent` accepting `TextWriter`.
- This also enables us to inspect backing fields for all of the various contents to lazily initialize them.
#358
- `true` has the opposite meaning now but most changes are due to new parameters names in `IViewEngine`
- use name names in `Microsoft.AspNet.Mvc.ViewFound` and not found events
- remove `IRazorPage.IsPartial` and `RazorView.IsPartial`
- remove `IsPartial` properties from `Microsoft.AspNet.Mvc.Razor.BeginInstrumentationContext` and end events
- add parameter checks to `RazorView` constructor; instances are not retrieved from DI
nits:
- remove unused `cacheKey` parameter from `RazorViewEngine.CreateCacheResult()`
- correct duplicate test names in `RazorPageTest`
- also `...OnPageExecutionListenerContext` -> `...OnPageExecutionContext`
- `IRazorViewEngine.MakePathAbsolute()` -> `GetAbsolutePath()`
- set `IsPartial` on all `IRazorPage` instances
- improve consistency of methods in `HtmlHelperPartialExtensions`
- a couple unnecessarily passed `htmlHelper.ViewData`
- add missing tests of these extension methods
- restore parameter checks in `CompositeViewEngine`
- reduce `List<string>` and remove enumerator allocations in `CompositeViewEngine`
nits:
- correct a few comments
- use `<seealso/>`
- do not blindly use `FindPage()` / `FindView()` result in `Exception.Message` or returned results
- failure scenarios involve new `Any()` calls but rarely additional `List<string>()` allocations
- change `ViewEngine_ViewNotFound` resource to be consistent with similar errors
- remove trailing period at end of searched locations list
nit: remove remaining `null` checks of `SearchedLocations` in not found cases; never `null` then
- #3307
- relative paths are now supported in `View()` calls from components and view components,
`Html.PartialAsync()` and similar calls, and `RazorPage.Layout` settings.
- support absolute paths, relative paths, and view location lookups consistently / everywhere
- support view paths in `TemplateRenderer` e.g. passing an absolute path to `Html.EditorFor()`
- take a big swing at the `IRazorViewEngine` and `IViewEngine` interfaces
- split lookups (view names) from navigation (view paths)
- remove `Partial` separation; use parameters to set `IsPartial` properties
- correct `ViewContext` copy constructor and add unit test
- extend unit tests to cover relative paths
- fix existing tests to handle newly-required extension in an absolute path
- add functional test that chains relative paths
nits:
- remove some YOLO line wrapping
- `""` -> `string.Empty`
This change significantly reduces the amount of string and List<ISymbol>
allocations that occur during compilation by changing the way
LiteralChunks are combined.
This is a low impact fix that addresses the performance issue, the design
issues that caused it still exist.
The problem here lies in what Razor fundamentally does - it parses HTML/C#
into tokens, and then combines them back into 'chunks' a representation
friendly to code generation. When presenting with a large block of static
HTML, Razor parses it into individual HTML tokens, and then tries to join
them in back into a single chunk for rendering. Due to details of Razor's
representation of chunks/tokens, the process of combining literals is too
expensive.
Mainly, what's done here is to not try to combine instances of
LiteralChunk. The process of merging them is too expensive and requires
lots of interm List<ISymbol> and string allocations.
Instead we produce a new 'chunk' ParentLiteralChunk, which doesn't do so
much up-front computing. Various pieces of the code that deal with
LiteralChunk need to be updated to deal with ParentLiteralChunk also,
which is the bulk of the changes here.
Note that we still have the potential for LOH allocations to occur during
codegen, but it's likely to occur O(1) for each large block of HTML
instead of O(N) as it did in the old code.
Ryan Nowak
Chris R
apxoht
Pranav K
Pavel Krymets
Stephen Halter
ryanbrandenburg
Daniel Kraemer
Nate McMaster
N. Taylor Mullen
Doug Bunting
Ben Adams
John Luo
Hao Kung
Cesar Blum Silveira