RC2
Pre-releaseASP.NET Core RC2 Release Notes
We are pleased to announce the release of ASP.NET Core RC2!
Get started with ASP.NET Core RC2
You can find details on the new features and bug fixes in RC2 for the following components on their corresponding release pages:
- Antiforgery
- Caching
- Common
- Configuration
- CORS
- DataProtection
- DependencyInjection
- Diagnostics
- dotnet-watch
- EntityFramework
- EventNotification
- FileSystem
- Hosting
- HtmlAbstractions
- HttpAbstractions
- Identity
- IISIntegration
- JsonPatch
- KestrelHttpServer
- Localization
- Logging
- Microsoft.Data.Sqlite
- Mvc
- Options
- PlatformAbstractions
- Razor
- RazorTooling
- Routing
- Scaffolding
- Security
- Session
- StaticFiles
- Templates
- Testing
- Tooling
- UserSecrets
- WebSockets
Breaking Changes
- For a list of the breaking changes for this release please refer to the issues in the Announcements repo.
Known Issues
-
Tooling known issues Please see the Known Issues list in the Tooling repo
-
EF Core: Error Installing into .NET Core Class Library
Attempting to install/restore EF Core into a .NET Core class library results in the following errors.
The dependency Remotion.Linq 2.0.2 does not support framework .NETStandard,Version=v1.5.
and/or
The dependency Ix-Async 1.2.5 does not support framework .NETStandard,Version=v1.5.
Workaround
You can workaround this issue by updating the
frameworks
section ofproject.json
to includeportable-net452+win81
in theimports
section."frameworks": { "netstandard1.5": { "imports": [ "dnxcore50", "portable-net452+win81" ] } }
For more details, see dotnet/efcore#5176.
-
EF Core: Performance Issue Adding a Large Number of Entities
In RC2 the time taken to add large number of entities to the context is non-linear. The slow down becomes impactful around 2000-5000 entities depending on the complexity of the model.
Workaround
To work around this issue, you can break the entities up into a series of batches and add each batch using a fresh context instance.
For more details, see dotnet/efcore#4831
-
EF Core: Scaffold-DbContext requires additional quoting in .NET Core/ASP.NET Core projects
When using the Scaffold-DbContext command in Package Manager Console for ASP.NET Core projects, you may encounter an error similar to the following.
The term 'localdb' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
Workaround
The workaround is to double quote the connection string by adding single quotes inside the double quotes.
PM> Scaffold-DbContext "'<connection string>'" <database provider>
For more details, see dotnet/efcore#5376.
-
EF Core: LINQ Provider Limitations
LINQ providers take time to build, and EF Core is no exception. The LINQ provider in RC2 is greatly improved over RC1, both in terms of performance and the queries it can successfully execute. There are still a number of queries that will either fail, or be partially evaluated in memory. We will continue to fix bugs, and increase the number of queries that can be evaluated thru RTM, though the LINQ provider will not be complete at this stage and improvements will continue for some time to come.
-
EF Core: Model Building Performance Regression
RC2 contains a performance regression that causes model building to be ~2x slower than it was in RC1. For most applications, this slow down will not be noticeable. This issue is fixed in our current code base and performance will be faster than RC1 in the next release.
-
HTTPS requests appear as HTTP in Azure Web Sites
Symptoms:
- HTTPS requests have HttpContext.Reqeuest.Scheme set to "http"
- Generated redirects and links use "http://" instead of "https://"
- OpenIdConnect and OAuth authentication will fail because the generated redirect url does not match the pre-registered address
[RequireHttps]
causes infinite redirects
Background:
When AspNetCoreModule forwards requests to the application it does so over HTTP and adds X-Forwarded-For and X-Forwarded-Proto headers to preserve the original remote IP and scheme. In Azure Web Sites there is a duplicate X-Forwarded-For value. The duplicate value is a problem because the middleware that reads the forwarded headers requires the same number of entries in X-Forwarded-For and X-Forwarded-Proto for security reasons.Workaround:
Add the following in Startup.ConfgiureServicesservices.Configure<ForwardedHeadersOptions>(options => { options.ForwardedHeaders = ForwardedHeaders.XForwardedProto });
This ignores the X-Forwarded-For header and allows X-Forwarded-Proto to be applied correctly.
-
EF Core: Package Manager Console Commands Require PowerShell 5
EF Core commands from Package Manager Console may fail with one of the following errors:
The expression after '&' in a pipeline element produced an object that was not valid. It must result in a command name, a script block, or a CommandInfo object.
or
Where-Object : Cannot bind parameter 'FilterScript'. Cannot convert the "Name" value of type "System.String"
or
Join-Path : Cannot bind argument to parameter 'Path' because it is null.
Workaround
To work around this issue upgrade to PowerShell 5.0 - https://www.microsoft.com/en-us/download/details.aspx?id=50395.
For more details, see dotnet/efcore#5327
-
EF Core: Installing tools in a UWP class library causes the Windows App Cert Kit to fail
If the UWP class library contains a reference to EF Core tools ("Microsoft.EntityFrameworkCore.Tools"), the Windows App Cert Kit will fail the AppContainerCheck test on any UWP apps that depend on this UWP class library.
Workarounds:
- Remove Microsoft.EntityFrameworkCore.Tools before deploying the UWP app.
- Add Microsoft.EntityFrameworkCore.Tools to the UWP application project instead of the class library project.
-
Need to update log location when deploying to an Azure App Service web app
Workaround:
Update web.config to remove the log location and it will get updated correctly when published.