Skip to content
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

Merged
merged 3 commits into from
Feb 13, 2023

Conversation

dougbu
Copy link
Member

@dougbu dougbu commented Feb 2, 2023

Copy link
Member Author

@dougbu dougbu left a 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❕

build.cmd Outdated Show resolved Hide resolved
Comment on lines +581 to +584
// 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.
Copy link
Member Author

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.

@dougbu
Copy link
Member Author

dougbu commented Feb 2, 2023

/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

Copy link
Member Author

@dougbu dougbu left a 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.

@@ -354,7 +357,7 @@ private byte[] SerializeHeader()
return Encoding.UTF8.GetBytes(message.ToString());
}

private void ValidateStreamForReading(Stream stream)
private void ValidateStreamForReading(Stream stream) // ???
Copy link
Member

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.

@dougbu
Copy link
Member Author

dougbu commented Feb 11, 2023

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 Content to all HttpResponseMessages" commit as well as a fix for ValidateStreamForReading(...)

- 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
@dougbu dougbu force-pushed the dougbu/Newtonsoft.Json.net6 branch from 0ac8d00 to 8d4b667 Compare February 11, 2023 05:16
@dougbu dougbu requested review from Tratcher, stephentoub and MattGal and removed request for TanayParikh February 11, 2023 05:17
@@ -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>
Copy link
Member Author

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
Copy link
Member Author

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.

Copy link

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
@dougbu
Copy link
Member Author

dougbu commented Feb 12, 2023

/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.

  • Updates to use binplaced msbuild from VS2022 on a VS2019 agent i.e. supporting net6.0 in msbuild while having old .NET Framework targeting packs available.
  • Switch to net6.0 and related infrastructure changes
  • Adjust tests to handle new netcoreapp3.1 and net6.0 behaviours
    • Note compiled-out tests will be restored (and fixed) in my next PR

Copy link
Contributor

@wtgodbe wtgodbe left a 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
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.

- fix comming **Real Soon Now:tm:** :grin:
@dougbu dougbu merged commit 0f4c624 into aspnet:main Feb 13, 2023
@dougbu dougbu deleted the dougbu/Newtonsoft.Json.net6 branch February 13, 2023 20:39
dougbu added a commit to dougbu/AspNetWebStack that referenced this pull request Feb 17, 2023
- 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
dougbu added a commit that referenced this pull request Feb 17, 2023
- 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
@dougbu dougbu added this to the 3.3.0 (5.3.0) milestone Feb 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants