/azp run

Grrr AZD

Codecov Report

Attention: Patch coverage is33.33333% with2 lines in your changes missing coverage. Please review.

Project coverage is 72.44%. Comparing base(9d5ca32) to head(a2a39e4).
Report is 51 commits behind head on main.

@@            Coverage Diff             @@##             main    #2963      +/-   ##==========================================+ Coverage   72.31%   72.44%   +0.12%==========================================  Files         288      288                Lines       59660    59529     -131     ==========================================- Hits        43145    43125      -20+ Misses      16515    16404     -111

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report?Share it here.

Anything I can do to move this along?

It's worth explicitly calling out that the the behavior ofBitConverter andBinaryPrimitives is not the same (BinaryPrimitives require specifying the endianness whileBitConverter uses the system's endianness). For netcore, it makes sense to specify little-endian conversion since netcore can be expected to run on big-endian systems. For netfx, it made sense to use the system endianness since it wasn't expected that netfx would run on big-endian systems (though I'm not sure how accurate that expectation is). Thus, bringing the netcore implementation to the netfx codebaseshould be safe.

In fact, all integer values in TDS should be represented in little endian unless it's specifically mentioned that they should be big endian. The only fields with special treatment are:

• VERSION inPL_OPTION_TOKEN
• PL_OFFSET andPL_OPTION_LENGTH inPRELOGIN
• SPID andLength in the packet header

It looks like we only touch the fed auth options packet and row level data field parsing in this PR, so little endian should be correct.