Mostly just a revert of the commit that removed this functionality, with a few changes:
* Perform proper JavaScript encoding in the script part of the database error page Views/BaseView.cs
* Use the builder pattern in the UseXyz extension methods on IApplicationBuilder (per #184). Also applying this to DatabaseErrorPageOptions to keep things consistent.
* Fixing a few tests that were getting the context from DI but putting it in a using block so that it got disposed (rather than letting DI handle disposing).
When there is an existing database and no migrations are present, then we should just display the standard error page as they are not using migrations and need to adjust their mapping code to match the existing schema.
Resolve#182
If a database exception is wrapped later in the request (after EF has logged it) then we were not displaying the database error page.
This was occurring in ASP.NET Identity where the exception was getting wrapped in an AggregateException.
We now walk the tree of inner exceptions looking for a match.
Also adding some extra logging as this was hard to debug without resorting to source code.
Rowan Miller
Pranav K
Kiran Challa
Brice Lambson
Arthur Vickers
N. Taylor Mullen
Praburaj
Hao Kung
mikary