Core: .NET Core 2.2.0 Preview 3

Created on 17 Oct 2018  路  19Comments  路  Source: dotnet/core

.NET Core 2.2.0 Preview 3

Release Notes
Download

Please report any issues you find with 2.2.0 Preview 3, either responding to this issue, creating a new issue or creating a new issue in one of the following repos:

announcement

Most helpful comment

the release notes seem poor, the entity framework one seems fine abd highlights the changes, but .net core and asp.net I can't work out what's changed easily

All 19 comments

what is the release strategy for OOB packages such as System.Diagnostics.DiagnosticSource? When can we expect to have them on nuget.org?

the release notes seem poor, the entity framework one seems fine abd highlights the changes, but .net core and asp.net I can't work out what's changed easily

Agree that it is very hard to locate the changes in preview releases. At very least, links to commit logs (or closed PR/issue logs) for the range of included changes would be very helpful!

@keithn @peppy maybe this helps: https://github.com/search?q=org%3Aaspnet+is%3Aissue+is%3Aclosed+milestone%3A2.2.0-preview3. _all issues closed in the 2.2.0 Preview 3 milestone_

Saw here: https://github.com/aspnet/Announcements/issues/323

what is the release strategy for OOB packages such as System.Diagnostics.DiagnosticSource? When can we expect to have them on nuget.org?

Adding @brianrob and @adamsitnik to comment on System.Diagnostics.DiagnosticSource

To my knowledge, all of the NuGet packages that are produced by the CoreFx build are published to nuget.org when we release. It doesn't look like any of the NuGet packages have been updated on nuget.org yet for any 2.2 preview releases.

@vancem, does DiagnosticSource follow this plan, or is it published to nuget.org on-demand?

I've run into an issue. Have the CORS values returned by preflight requests been changed?

curl 'https://server/api' -X OPTIONS -H 'Access-Control-Request-Headers: content-type' -H 'Access-Control-Request-Method: PUT' -H 'Origin: xxx'

2.2 Preview 2 (as well as 2.1) gives

Access-Control-Allow-Headers: content-type
Access-Control-Allow-Methods: PUT

2.2 Preview 3 gives

Access-Control-Allow-Headers: *
Access-Control-Allow-Methods: *

As I understand it, * is not yet very well supported, which explain why parts of our application is now broken.

@javiercn could you take a look at the CORS behavior change above?

@muratg Yes. We fixed this to make it spec compliant a few days ago, but seems that clients don鈥檛 support * very well.

@pranavkm we should just reflect the request headers here when all are allowed.

@memark what browser \ OS are you using?

@pranavkm We have seen the problem described above on

Microsoft Edge
Version 42.17134.1.0
OS: Windows 10 Pro, version 1803, build 17134.345

Internet Explorer 11
Version 11.345.17.134.0
OS: Windows 10 Pro, version 1803, build 17134.345

Google Chrome
Version 69.0.3497.100 (Official Build) (64-bit)
OS: MacOS Mojave (10.14)

Safari
Version 12.0 (14606.1.36.1.9)
OS: MacOS Mojave (10.14)

Firefox
Version 62.0.3 (64-bit)
OS: MacOS Mojave (10.14)

I ran into an issue caused by misconfiguration. According to this documentation https://docs.microsoft.com/en-us/aspnet/core/security/authentication/cookie?tabs=aspnetcore2x&view=aspnetcore-2.2, _Cookie.Expiration_ is obsolete. Yet I got no warnings or errors when I used _Cookie.Expiration_ instead of _ExpireTimeSpan_ in ASP.NET Core 2.2 Preview 3.

@javiercn @pranavkm could one of you guy create a bug under aspnet/cors for this issue?

@muratg I believe we already fixed this

hi, i know that https://github.com/aspnet/KestrelHttpServer/issues/1144 issue regarding the kestrel server not allowing invalid characters in headers was fixed in .NET Core 2.2.0-preview2 and it was working fine, but it seems that in .NET Core 2.2.0-preview3 the invalid characters are not accepted anymore and kestrel throws 400 like before.

Does anyone encountered this issue or know anything about it? Do I need to adjust some options or anything ?

Thank you.

@ionepaul it would be best to take the discussion on the bug you linked - @muratg @Eilon @Tratcher can you please take a look?

@ionepaul please open a new issue at https://github.com/aspnet/aspnetcore with the details for your scenario including a Fiddler or WireShark trace file please.

There is no configuration for this scenario, it should just work.

hi @Tratcher, just opened #4318 with all the details, it seems that is happening both for preview2 and preview3 only when running behind IIS.

Closing in favor of #2098 (RTW release)

Was this page helpful?
0 / 5 - 0 ratings