I'm starting to see that tests start running too soon before the application started. Increasing the wait time to a bigger number.
It will increase the test runtime of each selfhost variation by a couple more seconds, but it will increase the reliability.
- eventually will clean up IntelliSense -- removing classes users don't
need when editing a view
- will _not_ cleanup IntelliSense 'til VS stops using a private copy of
Microsoft.AspNet.Mvc.Razor.Host.dll or we update that copy
- all tests and MVC sample views still work fine
- issue #969
A couple of selfhost variations are failing on some of the new CI machines. While trying to reproduce I see that the klr.exe processes are lauching fine. But the tests fail for a couple of self-host variations. Only suspicion is this time out as the client gets a socket exception. It is possible that client is making a request before the server is ready.
This does not include the deployment helper on mono. So the test needs to point to a statically deployed application url to run.
There are some bugs in mono Httpclient like in case of 302's RequestMessage's Uri not modified, cookies not cleared in cookie container etc. I will file bugs in mono on those and this is a work around until then.
There is still more work and refactoring. This is a first step.
GetSourceLocation is frequently called to determine the location mappings
between the original document and the generated code.
The old implementation did a number of ToString and replace operations to
simplify the math on tracking the position - which put it front and center
in our performance measurements - about 25% of all execution time in a
sampling profile of our perf test.
The new code tracks position as code is written, and avoids allocations.
After these changes GetSourceLocation doesn't show up in the profile.
- focus on affect of `ModelMetadata.HasNonDefaultEditFormat` and
`IHtmlHelper.Html5DateRenderingMode`
- work through `TemplateRenderer` because individual templates only do
formatting in a few cases
- avoid overriding a datetime format if format was already customized
- primarily affects the default Date and Time editor templates because they
are often used due to `[DataType]` attributes with "default" edit formats
- `DisplayFormatString` and `EditFormatString` now based on attributes
- `HasNonDefaultEditFormat` is new
- confirm `DataType` and `ScaffoldColumn` in `CachedDataAnnotationsMetadataAttributes`
- add `DataType` property to `CachedDataAnnotationsMetadataAttributes` in support of `ComputeHasNonDefaultEditFormat()`
- provide doc comments and flesh out the implementation of `DisplayFormatString` and `EditFormatString`
nits:
- add comment about _not_ overriding `ComputeIsComplexType()` in `CachedDataAnnotationsModelMetadata`
- restore alphabetic order in `CachedDataAnnotationsMetadataAttributes`
- seal `SimpleDisplayText` in `CachedModelMetadata<TPrototypeCache>`, matching MVC 5.2
jacalvar
Chris Ross
Praburaj
N. Taylor Mullen
Pranav K
Hao Kung
harshgMSFT
Ryan Nowak
Shannon Deminick
dougbu
sornaks
Levi B