- use specific workaround for Microsoft/vstest#428
- generating an executable for a test project is a bit too weird
- also work around dotnet/sdk#926
- generating an executable covered this as well
nit: add and update comments about other workarounds in the functional tests project
- #5873
- creating an EXE for the test project seems to work around #5873
- also avoids dotnet/sdk#926 when building in Visual Studio
nit: clean up duplicate test data
- 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`
- aspnet/Testing#248
- xUnit no longer supports .NET 4.5.1
- update AppVeyor config so this framework version is available
- build tests for desktop .NET only on Windows
This is part 1 of the right fix for the directive getting removed. This
pass has the wrong order, an it should be running sooner before the
directive is processed by the default processor.
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
Ryan Brandenburg
Pranav K
Doug Bunting
Steve Gordon
Nate McMaster
Ajay Bhargav Baaskaran
N. Taylor Mullen
Stefan Nikolei
martincostello
Steve Smith
Ryan Nowak
Jass Bagga
Kiran Challa