-
Notifications
You must be signed in to change notification settings - Fork 354
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test Formatting assemblies w/ net6.0
#384
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Calling on lots of reviewers because this PR mixes a few things together as I expand our test matrix. Thanks for your help❕
// Cannot Mock a Stream and let JsonWriter write to it. Writer will use ReadOnlySpan in this case and such | ||
// parameters are not currently mockable. See moq/moq4#829, moq/moq4#979, and dotnet/runtime#45152. | ||
// Override here avoids the Mock<Stream> and should confirm this Stream is not closed. Also adds an | ||
// additional check of the written text. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stephentoub this relates to one of our email conversations. Thanks for your pointer to dotnet/runtime#45152 and helping me understand what's happening.
Thoughts from all reviewers much appreciated: Should I simply replace MediaTypeFormatterTestBase.WriteToStreamAsync_WhenObjectIsNull_WritesDataButDoesNotCloseStream along these lines❔ Would need a protected
property containing the expected Stream
content for a null
value. But I'm thinking verifying what's written makes sense. I'm also thinking the BSON case might be more difficult to confirm.
test/System.Net.Http.Formatting.Test/Handlers/ProgressMessageHandlerTest.cs
Outdated
Show resolved
Hide resolved
test/System.Net.Http.Formatting.Test/HttpMessageContentTests.cs
Outdated
Show resolved
Hide resolved
/fyi successful runs on the CI will likely take a week because the v4.5 targeting pack is not available on VS2022 build agents right now |
test/System.Net.Http.Formatting.Test/Formatting/BsonMediaTypeFormatterTests.cs
Show resolved
Hide resolved
test/System.Net.Http.Formatting.Test/HttpMessageContentTests.cs
Outdated
Show resolved
Hide resolved
test/System.Net.Http.Formatting.Test/HttpMessageContentTests.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stephentoub, @Tratcher, @karelz, @MihaZupan, the last commit is directed toward making the Formatting behaviour more consistent on all platforms and I'd appreciate your feedback. The commit description lists what I believe will change from Formatting 5.2.9 to 6.0.0 (our next release) related to conversations in this PR.
side note: Total consistency won't come from this (because we have some restrictions in the netstandard1.3
assembly) and is probably impossible. But, with respect to HttpResponseMessage.Content
, nothing changes when moving from net461
to net7.0
.
test/System.Net.Http.Formatting.Test/Formatting/JsonMediaTypeFormatterTests.cs
Outdated
Show resolved
Hide resolved
test/System.Web.Http.Test/Controllers/VoidResultConverterTest.cs
Outdated
Show resolved
Hide resolved
@@ -354,7 +357,7 @@ private byte[] SerializeHeader() | |||
return Encoding.UTF8.GetBytes(message.ToString()); | |||
} | |||
|
|||
private void ValidateStreamForReading(Stream stream) | |||
private void ValidateStreamForReading(Stream stream) // ??? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, this seems like a bug, it should have checked CanSeek before setting the Position, not CanRead. I have seen some Streams return CanRead false after they're done, so that might have avoided the bug.
Ran enough tests locally to confirm the last commit here does what it says on the tin. Will remove that commit and instead comment out broken tests and fix the infrastructure issue seen on the CI. Expect a new PR built on the "Add |
- expand our text matrix to include a modern (and LTS) TFM - change how Formatting test assemblies are found - `netcoreapp` is no longer the only relevant folder prefix - use the latest .NET 6 SDK - install the 2.1.x runtime in the pipeline - don't require .NET in VS - will use binplaced `msbuild` instead - have `git` ignore the new .msbuild/ folder - react to new `Exception.Message`s in `netcoreapp3.1` - handle different formatting of argument info in `ArgumentException.Message`s - handle slightly greater `decimal` precision in a `JsonReaderException.Message` - react to new `Exception.Message`s and other changes in `net6.0` - handle different `Message` in `InvalidOperationException`s about invalid request URIs - react to other changes in `net6.0` - handle inability to mock a `Stream` if a writer passes a `ReadOnlySpan<byte>` in `net6.0` - see devlooped/moq#829, devlooped/moq#979, and dotnet/runtime#45152 about the issue - skip tests failing due to `HttpResponseMessage` changes - see dotnet/runtime@b48900f which introduced this - nits: - simplify define use now that `NETCOREAPP3_1_OR_GREATER` and so on are available - clean up .gitignore
0ac8d00
to
8d4b667
Compare
@@ -20,7 +20,7 @@ | |||
<Reference Include="System.Buffers, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51, processorArchitecture=MSIL"> | |||
<HintPath>..\..\packages\System.Buffers.4.5.1\lib\net461\System.Buffers.dll</HintPath> | |||
<SpecificVersion>False</SpecificVersion> | |||
<Private>False</Private> | |||
<Private>True</Private> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wasn't reliably copied in local builds for me
@@ -0,0 +1,37 @@ | |||
# Lifted from https://github.com/dotnet/arcade/blob/main/eng/common/tools.ps1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MattGal this is pretty much what you suggested in dotnet/arcade#12402. Incorporating it in build.cmd was the only bit I added.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
- nit: clean up a few comments and tighten scripting up
/ping reviewers I reset reviews because this works differently than the original PR. But it's working cleanly both locally and in the CI 😁 Suggest reviewers pick and choose what they sign off on e.g.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Signing off on msbuild bits + .yml, global.json, .gitignore, and build.cmd
@@ -0,0 +1,37 @@ | |||
# Lifted from https://github.com/dotnet/arcade/blob/main/eng/common/tools.ps1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
test/System.Net.Http.Formatting.Test/Handlers/ProgressMessageHandlerTest.cs
Outdated
Show resolved
Hide resolved
- fix comming **Real Soon Now:tm:** :grin:
- fix aspnet#386 - reenable `net6.0` tests disabled in aspnet#384 for this issue - also, check `Stream.CanSeek` less when calculating `HttpMessageContent.ContentLength` value - use inner `HttpContent.Headers.ContentLength` if available - this changes behaviour slightly for both requests and responses - observable as `HttpMessageContent.Headers.ContentLength!=null` for empty messages - for responses, avoids `ContentLength==null` versus `ContentLength==0` inconsistencies (depending on platform) - `ContentLength==null` may still occur in some corner cases (which existed before) - e.g. when inner `HttpContent` doesn't know its length and `ReadAsStreamAsync()` hasn't completed - main change means `HttpResponseMessage`s we expose to user code are consistent across platforms - note: user code won't see `EmptyContent` in `HttpResponseMessage`s we create
- fix #386 - reenable `net6.0` tests disabled in #384 for this issue - also, check `Stream.CanSeek` less when calculating `HttpMessageContent.ContentLength` value - use inner `HttpContent.Headers.ContentLength` if available - this changes behaviour slightly for both requests and responses - observable as `HttpMessageContent.Headers.ContentLength!=null` for empty messages - for responses, avoids `ContentLength==null` versus `ContentLength==0` inconsistencies (depending on platform) - `ContentLength==null` may still occur in some corner cases (which existed before) - e.g. when inner `HttpContent` doesn't know its length and `ReadAsStreamAsync()` hasn't completed - main change means `HttpResponseMessage`s we expose to user code are consistent across platforms - note: user code won't see `EmptyContent` in `HttpResponseMessage`s we create
net6.0
supportnetcoreapp
is no longer the only relevant folder prefixException.Message
s innetcoreapp3.1
ArgumentException.Message
sdecimal
precision in aJsonReaderException.Message
Exception.Message
s and other changes innet6.0
Message
inInvalidOperationException
s about invalid request URIsHttpResponseMessage.Content != null
after construction (a test-only change fortunately)Stream
if a writer passes aReadOnlySpan<byte>
innet6.0
- see System.NotSupportedException : Cannot create boxed ByRef-like values. devlooped/moq#829, Support ref structs on mock Setup parameter devlooped/moq#979, and Developers using reflection invoke should be able to use ref struct dotnet/runtime#45152 about the issueNETCOREAPP3_1_OR_GREATER
and so on are available