This change removes the dependency of TempData on the IHttpContextAccessor
by creating an ITempDataDictionaryFactory abstraction. In general, no one
will replace the factory, it's just indirection.
This allows us to drop our dependency on IHttpContextAccessor, and move it
to the functional tests where we specifically depend on it.
The bulk of code churn here is to update tests that use TempData.
This change removes [Activate] support from TagHelpers. TagHelpers which
need access to context should use [ViewContext] to have it injected. To
access services, use constructor injection.
This change removes [Activate] from ViewComponents. Accessing context
should be done through [ViewComponentContext]. Accessing services should
be done though constructor injection.
- remove useless `configuration` variables and `Configuration` instances
- remove "Review" code comment
- unintentionally included in commit 4b5dd19
- reduce repeated code in `TestHelper` for functional tests
- `CreateServer()` methods had duplicate code, an ambiguous match, and an odd order
- rename `GetTestConfiguration()` to `UseCultureReplacer()` in functional tests
services
* Added WithControllersFromServiceProvider that replaces the default
controller activator with a service based one.
* Move activation to DefaultControllerFactory
* Modify [Activate] behavior so that it no longer activates services. Use
[FromService] attribute to hydrate services
Fixes#1707
- React to aspnet/Razor#221
- Modified existing TagHelper tests to no longer rely on ContentBehavior.
- Updated signatures of TagHelperExecutionContext and TagHelperContext pieces.
Adding dependencies and commands for iis, web listener and khestrel to each
site.
Each website comes with a readme.md to 'anchor' the otherwise empty
folder. We have another work item tracking adding content to these.
Once VS sees a project with a wwwroot, it wants to assign a port for iis,
so I let it.
These tests verify that per-request services can be injected into assets
that users provide/implements (filters, constraints, controllers, views,
etc).
The purpose is to verify that the services are correctly resolved from the
per-request service container, and don't have state that lingers and
influences the next request. This is important because changing the
lifetime of a framework services could easily impact the lifetimes of
others, and ultimately of something the user created.