This change addressed a race condition in the ObjectMethodExecutor where
the default argument values array can become visible before it is
initialized. If a second observer accesses the array while it is being
initialized, it can observe a null value for a reference type parameter,
leading to a nullref.
The fix here is to make everything immutable and initialize it all up
front. There's no reason to create an OME without eventually running it,
so there's no downside to doing the initialization up front.
- thanx to @NTaylorMullen for initial conversion
- e.g. AssemblyInfo.cs files were already minimized or removed :)
- allow `>=` RC3 CLI's to build and run MVC
- work around several dotnet migration issues; see #5482
- disable full .NET Framework runs of functional tests; see #5873
- remove `Microsoft.DotNet.InternalAbstractions` and `System.Xml.XmlDocument` dependencies
- remove project.json (!!), *.xproj, .notest, and web.config files
Redo earlier changes:
- apply test migration to .NET 4.5.2 in *.csproj world
- see 63507c8 for previous, project.json work
- apply dependency version downgrade from 0097e40 in *.csproj world
Make other test-related changes:
- make Microsoft.AspNetCore.Mvc.TestDiagnosticListener a regular class library
- add support for `/p:GenerateBaselines=true` for functional and Razor.Host tests
- separate `GetCSharpTypeName_ReturnsCorrectTypeNames_ForOutParameter()` test
- work around inability to deserialize a odd `ref` type
- xUnit and vstest now serialize / deserialze test data more often
- skip poor test mentioned in #5768
- work around Microsoft/vstest#392
- rename tests to avoid duplicates
- work around Microsoft/vstest#419
- set up created `AppDomain`s with current `ApplicationBase`
This change ensures that setting ExceptionContext.Result will always
execute if set. The problem with 1.1.0 is that when we had a real short
circuit the wrong set of conditions were checked. I suspect that when you
set ExceptionFilter.Result and didn't short circuit that result filters
were also running (which is a bug).
Added a few tests that verify that the result doesn't trigger result
filters.
I did some general cleanup on this code path to make the state transitions
more clear.
No exception was thrown -> BeginResult
Exception was handled -> ExceptionHandled
Exception was not handled -> gets rethrown
- #5642
- lazy-load `ValidationEntry.Model`
- avoids `Exception`s when moving to a property that will not be validated
nits:
- remove duplicate code in `ValidationVisitor`
- clarify "all properties of" doc comments
- also add missing `<param>` doc in `ViewDataInfo`
- Added implementation of overloads where you can specify the fragment to redirect to.
- Added unit tests
- Added XML comments, including missing documentation of existing members
- #5499
- switch `foreach` to `for` and use less Linq when accessing `modelMetadata.Properties`
- change backing field for `ModelExplorer.Properties` from a list to an array
David Fowler
Pranav K
Coskun Sunali
Ryan Nowak
Nate McMaster
jacalvar
Steve Gordon
Ryan Brandenburg
N. Taylor Mullen
Stefan Nikolei
Jass Bagga
Nate McMaster
Kiran Challa
Doug Bunting
Joonas Westlin
hiiru
Steve Smith
Joonas Westlin
Daniel Roth
Julian Dominguez