Bump Serilog.Sinks.XUnit, Serilog and xunit.extensibility.core

[dependabot]

Bumps Serilog.Sinks.XUnit, Serilog and xunit.extensibility.core. These dependencies needed to be updated together.
Updates Serilog.Sinks.XUnit from 3.0.3 to 3.0.5

Commits

• See full diff in compare view

Updates Serilog from 2.10.0 to 2.12.0

Release notes

Sourced from Serilog's releases.

v2.12.0

Highlights of 2.12.0

Improved and expanded <Nullable>enable</Nullable> support

A huge number of commits have gone into completing and refining non-null reference type annotations, which now cover the entire public Serilog API. The Serilog project itself now builds with non-null reference type checking globally enabled 🎉

IAsyncDisposable support

Sinks that need to flush changes using asynchronous APIs can now implement IAsyncDisposable and prevent the possibility of deadlocking while waiting for tasks to complete.

To drive this, Logger can now be disposed via using async:

await using var log = new LoggerConfiguration().CreateLogger();

and the Log class provides Log.CloseAndFlushAsync():

await Log.CloseAndFlushAsync();

DateOnly and TimeOnly support

The DateOnly and TimeOnly types introduced in .NET 6 are now correctly handled as scalar values when capturing.

Merged PRs

• #1713, #1716, #1715, #1722, #1721, #1720, #1729 - improved non-null reference type annotations (@​SimonCropp)
• #1702 - DateOnly and TimeOnly support (@​SimonCropp)
• #1764, #1703, #1708, #1709, #1712, #1724, #1730, #1747 - build and dependency updates (@​SimonCropp)
• #1723, #1728, #1731, #1732, #1734, #1735, #1733, #1736, #1739, #1746, #1745, #1741, #1742 - code clean-up and modernization (@​SimonCropp)
• #1750 - IAsyncDisposable support for Logger and sinks (@​nblumhardt)
• #1699 - fix some XDOC documentation (@​sungam3r)
• #1719 - remove redundant ! operator from null in conditions (@​sungam3r)
• #1725 - introduce file-scoped namespaces (@​sungam3r)
• #1700, #1704, #1707 - more nulllable annotation updates (@​nblumhardt)
• #1711 - fix support for ValueTuple (@​SimonCropp)

v2.11.0

• #1503 - make some local functions static to avoid scope capture (@​SimonCropp)
• #1561 - add support for collections/string[] to key-value settings (@​stochmal)
• #1588, #1591, #1593, #1594, #1597 - nullable reference type annotations and language version updates (@​SimonCropp)
• #1595 - net5.0 target (@​nblumhardt)
• #1652 - fix capturing of anonymous types in .NET interactive (@​KZedan)
• #1641 - corrected documentation comments for MessageTemplateFormatMethod (@​JinsPeter)
• #1635 - fix destructuring of Memory<T>/ReadOnlyMemory<T> and non-reflection-compatible properties e.g. of type Span<T> (@​skomis-mm)
• #1625 - update issue template (@​augustoproiete)
• #1664 - update ILogger documentation (@​erichiller)

Commits

• 9f86301 Merge pull request #1705 from serilog/dev
• 47df92d Fix nullability of LogContext.PushProperty value arg (#1751)
• 7740c90 Initial support for IAsyncDisposable sinks (#1750)
• 4d13be5 guard against null (#1742)
• fd36c3e remove redundant type names (#1741)
• 3bd65ef remove redundant LogEventLevel (#1745)
• 1819ee7 refs (#1747)
• e0c533d minor cleanups (#1746)
• 70e729d use some patterns (#1739)
• c5a5b44 global usings (#1736)
• Additional commits viewable in compare view

Updates xunit.extensibility.core from 2.4.1 to 2.4.2

Commits

• f110e5b v2.4.2
• 848d94d Update dependencies
• 42307e8 Fixes #2556: Xunit.Sdk.MultipleException Empty
• 7eba502 Port test changes from 1dd43ce684cc6d50bf726042173956e6bda2fa3b
• 211aa27 Make sure we use msbuild.exe (from Visual Studio) and not msbuild.bat (from M...
• 878d209 Add tests for KeyValuePair<> equivalence (including Dictionaries with collect...
• 32d21fb Add tests for KeyValuePair<>/Dictionary ArgumentFormatter update
• 1109d48 Codify that arrays and lists are equivalent
• 19618ef Port #2463 to v2
• b88fee5 PerformDefinedConversions handles multiple conflicting conversions
• Additional commits viewable in compare view

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Note
Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

[pull-request-quantifier-deprecated]

This PR has 2 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

---

Quantification details

Label      : Extra Small
Size       : +1 -1
Percentile : 0.8%

Total files changed: 1

Change summary by file extension:
.csproj : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

• Fast and predictable releases to production:
  • Optimal size changes are more likely to be reviewed faster with fewer
    iterations.
  • Similarity in low PR complexity drives similar review times.
• Review quality is likely higher as complexity is lower:
  • Bugs are more likely to be detected.
  • Code inconsistencies are more likely to be detected.
• Knowledge sharing is improved within the participants:
  • Small portions can be assimilated better.
• Better engineering practices are exercised:
  • Solving big problems by dividing them in well contained, smaller problems.
  • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

• Use the PullRequestQuantifier to quantify your PR accurately
  • Create a context profile for your repo using the context generator
  • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
  • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
  • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
• Change your engineering behaviors
  • For PRs that fall outside of the desired spectrum, review the details and check if:
    • Your PR could be split in smaller, self-contained PRs instead
    • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

• One line was added: +1 -0
• One line was deleted: +0 -1
• One line was modified: +1 -1 (git diff doesn't know about modified, it will
  interpret that line like one addition plus one deletion)
• Change percentiles: Change characteristics (addition, deletion, modification)
  of this PR in relation to all other PRs within the repository.

---

Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

[pull-request-quantifier-deprecated]

This PR has 2 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

---

Quantification details

Label      : Extra Small
Size       : +1 -1
Percentile : 0.8%

Total files changed: 1

Change summary by file extension:
.csproj : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

• Fast and predictable releases to production:
  • Optimal size changes are more likely to be reviewed faster with fewer
    iterations.
  • Similarity in low PR complexity drives similar review times.
• Review quality is likely higher as complexity is lower:
  • Bugs are more likely to be detected.
  • Code inconsistencies are more likely to be detected.
• Knowledge sharing is improved within the participants:
  • Small portions can be assimilated better.
• Better engineering practices are exercised:
  • Solving big problems by dividing them in well contained, smaller problems.
  • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

• Use the PullRequestQuantifier to quantify your PR accurately
  • Create a context profile for your repo using the context generator
  • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
  • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
  • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
• Change your engineering behaviors
  • For PRs that fall outside of the desired spectrum, review the details and check if:
    • Your PR could be split in smaller, self-contained PRs instead
    • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

• One line was added: +1 -0
• One line was deleted: +0 -1
• One line was modified: +1 -1 (git diff doesn't know about modified, it will
  interpret that line like one addition plus one deletion)
• Change percentiles: Change characteristics (addition, deletion, modification)
  of this PR in relation to all other PRs within the repository.

---

Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.