Version 2.x (WIP...)

[StefH]

Version 2.x only supports:

• .NET Framework 4.8
• .NET 8.0

[codecov]

Codecov Report

❌ Patch coverage is 74.78261% with 87 lines in your changes missing coverage. Please review.
✅ Project coverage is 35.58%. Comparing base (f6c5225) to head (02228e5).

Files with missing lines	Patch %	Lines
...rc/WireMock.Net.Minimal/Owin/WireMockMiddleware.cs	84.12%	37 Missing ⚠️
...Mock.Net.Minimal/Owin/GlobalExceptionMiddleware.cs	55.55%	12 Missing ⚠️
...ock.Net.Minimal/Owin/Mappers/OwinResponseMapper.cs	47.05%	9 Missing ⚠️
...Mock.Net.Minimal/Owin/Mappers/OwinRequestMapper.cs	46.15%	7 Missing ⚠️
...Net.Minimal/Owin/AspNetCoreSelfHost.NETStandard.cs	45.45%	6 Missing ⚠️
...Mock.Net.Minimal/Owin/WireMockMiddlewareOptions.cs	45.45%	6 Missing ⚠️
src/WireMock.Net.Minimal/Owin/HostUrlOptions.cs	0.00%	4 Missing ⚠️
src/WireMock.Net.Minimal/Http/HttpClientBuilder.cs	0.00%	2 Missing ⚠️
src/WireMock.Net.Minimal/Matchers/XPathMatcher.cs	50.00%	1 Missing ⚠️
...reMock.Net.Minimal/Owin/AspNetCoreSelfHost.Cors.cs	50.00%	1 Missing ⚠️
... and 2 more

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1359      +/-   ##
==========================================
- Coverage   35.71%   35.58%   -0.14%     
==========================================
  Files         152      152              
  Lines       34539    34702     +163     
==========================================
+ Hits        12337    12350      +13     
- Misses      21777    21929     +152     
+ Partials      425      423       -2     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Kielek]

@StefH, some feedback:

1. It will be great to still have support for .NET Framework 4.6.2. It has normal support until Jan 12, 2027. The downside - there is no possibility to update to XUnit.v3. This package is used under OpenTelemetry Contrib repository. And various vendors still needs to offer support for ancient frameworks.
2. I have executed build locally, there is a lot of NU1902, NU1903, NU1904 warnings. All of them are related to different levels o security vulnerabilities. Part of them affects production dependencies.

[StefH]

Thanks for your response.

About 1: WireMock.Net is mostly used in unit tests. So how many % of those unit tests project are going to use an older framework like the one you mentioned? I think that supporting older frameworks in a main project and testing this in a unit test project is related but not always 1 to 1....

I will think on this and maybe support that one instead of 4.8

About 2: the question is how critical any security issue is because WireMock is used for testing, not for production code.

[Kielek]

Thanks for your response.

About 1: WireMock.Net is mostly used in unit tests. So how many % of those unit tests project are going to use an older framework like the one you mentioned? I think that supporting older frameworks in a main project and testing this in a unit test project is related but not always 1 to 1....

I will think on this and maybe support that one instead of 4.8

It will be great. I have had similar discussions about other, testing only library - Verify. After 1,5 year author bringed back support for this old framework. I think that the requestor was .NET team.

About 2: the question is how critical any security issue is because WireMock is used for testing, not for production code.

I think that here are 2 aspects to consider:

.NET SDK 9 for first release switchted settings to (then it was rollbacked, but some project kept it in place). I am not sure what is the current state:

  <PropertyGroup>
    <NuGetAudit>true</NuGetAudit>
    <NuGetAuditMode>all</NuGetAuditMode>
    <NuGetAuditLevel>low</NuGetAuditLevel>
  </PropertyGroup>

With this + treat warnings as errors, which is pretty common, at least in my buble, it leads to the breaking compilation. Usually, there is a possibility to fix such changes basicaly by bumping transitive packages, but it is just inconvinient. IMO it is better to fix such cases centrally,

The second aspect are security scans. I will consider OpenTelemetry as an example. Some end-users/companies making additional source code scans, not only shipped libraries. If we have any known vulnerable dependencies, there are at least yellow flags and we need to explain that the production code is not affected. With this, this project has strict rules to fix all such warnings.

Thanks for maintaining this library, I know that it takes more time than people usually thinks.