- #3066
- reduce `TestServer` -> `PhysicalFileProvider` -> `FileSystemWatcher` count enough to run with Core CLR on Linux
- remove use of `HttpClient.DefaultRequestHeaders`; any client change affects other tests
- remove use of `RequestBuilder` class; creates a per-test `HttpClient` and requires the `TestServer`
- updated a few expectations because `CommonTestEncoder` does JavaScript a bit differently
- "JavaScriptEncode[[...]]" -> "JavaScriptStringEncode[[...]]"
- side benefit: xUnit reports functional tests execute for only ~12.4s; was >30s before this change
Infrastructure: Enhance `MvcTestFixture`
- handle `ConfigureServices()` methods that are not `void`
- handle `Configure(IApplicationBuilder, ILoggerFactory)`
- ensure server is initialized with consistent `CurrentCulture` and `CurrentUICulture`
- add `FilteredDefaultAssemblyProviderFixture<TStartup>` and `MvcEncodedTestFixture<TStartup>`
- add `MvcTextFixture.AddAdditionalServices()` extension point supporting these
- do not expose the `TestServer`; an anti-pattern for tests to manipulate the server
- update class names to match containing files
- use existing `TestApplicationEnvironment`
- apply some `MvcTestFixture` improvements to the shared `TestApplicationEnvironment` class
- remove unused methods from `TestHelper`
nits:
- touched-up some leftover `_app` &c declarations to be more explicit and minimize `using`s
- moved statements into correct sections of methods in `RoutingTests`
- removed `TestLoggerFactory` and related classes from `TagHelperSampleTest`
with MVC5.
This change removes the behavior in model binding to validate values 'on
the wire' for requiredness instead of the looking at the model. This
restores the behavior of [Required] for model binding to the MVC5
semantics.
This part of the change removes default value support from ModelBinding.
Updated some unit tests to verify that it does nothing in that case.
Deleted a functional test as it was pure duplication of another
(supported) case where the property has a pre-initialized value.
- see issues aspnet/DependencyInjection#193 and #1612
- use `TryAdd()` in `MvcServices` for the `IAssemblyProvider`
Move `ApplicationBasePath` handling into `RazorPreCompileModule`
- restores view precompilation in functional tests of sample sites
- if we need this, others will as well
- override `IApplicationEnvironment` but get folder from `ProjectContext`
- also remove remaining `IServiceProvider` implementations in this code
test fixes:
- simplify `IApplicationEnvironment` override
- move override logic into `TestHelper.CreateServer()` methods
- remove `LoggerFactory` setup
- does not seem to require special-casing
- remove unused `ITestConfigurationProvider` / `TestConfigurationProvider`
- remove `TestAssemblyProvider` classes
- no longer required
- remove `ReplaceCallContextServiceLocationService` test helper
- change MVC sample to fully-qualify config.json path
- avoids `ReplaceCallContextServiceLocationService` need in `MvcSampleTests`
- no longer required for other tests
nit: remove unused `_serviceProvider` and constructor overload in `RazorPreCompiler`
This change adds support for our three-valued logic to the default value
handling part of the MutableObjectModelBinder.
The issue is that we want to look up a default value when a 'greedy' model
binder returns true but doesn't find a value.
We also don't want to call the property setter unless there is:
1). A value from model binding OR
2). A default value
See #1695 for a detailed explanation. This change builds support into the
system for the case that a model binder returns true without setting a
value for the Model.
In this case, validation will be skipped if it's a top-level object.
Note that explicitly setting null will still run validation.
The issue here is that a model state error is added with the model name
'doubled'. This is on a fairly obscure code path and the code dates back
to the original WSR git checkin of webapi. There are no wsr tests that
verify this behavior.
The cause here is that our 'greedy' model binders (like
FromHeaderModelBinder) return 'true' whether or not they successfully
found a model, because they don't want other model binders to run.
This also has an effect on the validation system. That means that
validators will run and attempt to validate the model (which may be null).
That's that rare case where we get to this code path.
Pranav K
Doug Bunting
Ryan Nowak
N. Taylor Mullen
Hao Kung
Harsh Gupta