- Move the Mvc.Performance project from test/ to benchmarks/.
- Remove the Version attribute on PackageReference.
- Add a reference to two PackageLineup's.
- Add snippet to README explaining the additional requirement to run build.cmd /t:restore.
- Add a target to check that packages have been pinned.
If you give ModelExpressionProvider a lambda with a private property
you'll end up here. This wasn't common before, but it seems like users
are more likely to try it with pages.
Model Metadata and Model Binding don't handle private properties, so
supporting it in Model Expressions seems less than useful.
This isn't a breaking change because this case would have resulted in a
null-ref. Addresses #6400
This changeset reckonciles the binding work we did for pages with
controllers.
A quick summary:
- Moves [BindProperty] to the MVC namespace (#6401)
- Makes [FromRoute] and friends behave consistently (#6402)
- Makes [BindProperty] work with controllers (untracked)
* Generate full pdbs for views on desktop and re-enable runtime error tests
StackTraceHelper \ PortablePdbReader used by Diagnostics is only useful for
reading portable pdbs on disk. However pdbs produced by views are entirely
in memory and therefore cannot be read. Consequently
we choose to generate full pdbs for views on Windows (when possible).
This doesn't go through the Razor tag helper discovery pipeline because
this can really only ever work for ITagHelper based taghelpers. So
there's really no point in reusing that logic, which would be hard
anyway.
- Prior to this change using asp-page-handler on its own did not create correct `<form>` elements. There were multiple issues, one as that the `FormTagHelper` would purposefully drop into a no-op code path. Second is the `DefaultHtmlGenerator` didn't call through to the `UrlHelper` correctly.
- Added functional test cases to validate asp-page-handler can live on its own on a form tag. This also included adding a variant where method="post".
- Added a `FormTagHelper` unit test to validate the `PageHandler` property is consumed properly.
#6208
- Added functional test to verify `asp-*` attributes on form taghelpers work as expected.
- Added a unit test to validate `FormTagHelper` behaves as expected.
- Moved `Method == "get"` checks into appropriate code paths. These include the one where a user specifies an empty or non-existent `action` attribute and where a user doesn't utilize any `asp-*` attributes. In the later, we default `Method` to `"get"` if it's not provided.
#6006
- Added a test case to the HtmlGeneration functional test (the one verifying complex FormTagHelpers).
- Added unit test verifying antiforgery behavior when it's the only provided parameter.
#6006
- Added functional test to validate that non-attributed form tags have an antiforgery input generated. Re-generated baseline to reflect changes.
- Added a unit test to validate that parameterless `FormTagHelper`s behave as expected.
#6006
The issue here is that route values used for action selection are
'global'. That means that pages need to have a 'null' route value for
'action' and controllers need to have a 'null' route value for pages. This
is the same way that areas work.
The fix is to move the 'merge' of route values up to a level where pages
and controllers can work together. Since ADPs use the russian-doll
pattern, the fix is to run this 'merge' in the controller ADP, but after
all of the ADs have been created.
The View Engine now needs to know about pages :(. This isn't ideal but the
view engine needs to know what set of search paths to use. This was
already hardcoded for controllers vs controllers + areas. It felt right to
further hardcode instead of introduce a wierd abstraction that we only
use.
Additionally pages use a view location expander to implement an ascending
directory search.
- 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 allows specifying all it's dependencies rather than for consuming projects to do this
* Remove unused APIs
* Fix weird downgrade warnings that show up due to P2P references