修正一些包的风险，提取一些包特性到公共文件中（不同于Directory.Build.props） #275
Conversation
新增对 .NET 9.0 的支持，更新多个项目的 `TargetFrameworks` 属性以兼容最新框架版本。 引入 `WebApiClientCore.Common.props` 和 `WebApiClientCore.Extensions.Common.props` 公共属性文件，统一管理 `Nullable`、`TargetFrameworks` 等配置，减少重复代码并提升可维护性。 修补风险项 GHSA-ghhp-997w-qr28 GHSA-5crp-9r3c-p9vr GHSA-7jgj-8wvc-jh57 GHSA-cmhx-cq75-c4mj
WalkthroughThis update introduces several infrastructure and code improvements across the project. Common MSBuild property files are added and imported into various project files to centralize and standardize build configurations. Multiple projects now target the new .NET 9.0 framework, with corresponding updates to package references where necessary. Some code files receive minor adjustments for improved nullability handling and method signatures. Resource embedding and code generation settings are aligned for localization files. No changes are made to the public API surface except for a method signature update in a nested comparer class and a base class change in a test class. Changes
Sequence Diagram(s)sequenceDiagram
participant BuildSystem
participant ProjectFile
participant CommonProps
BuildSystem->>ProjectFile: Start build
ProjectFile->>CommonProps: Import shared properties
CommonProps-->>ProjectFile: Apply common settings (nullable, TFMs, docs, etc.)
ProjectFile-->>BuildSystem: Build proceeds with centralized config
Poem
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🔭 Outside diff range comments (1)
App/App.csproj (1)
1-29: 💡 Verification agent🧩 Analysis chain
Consider importing common property files
Other projects in this solution are being updated to import common property files. Consider following this pattern for consistency across the solution.
<Project Sdk="Microsoft.NET.Sdk.Web"> + + <Import Project="..\props\WebApiClientCore.Common.props" /> <PropertyGroup> <OutputType>Exe</OutputType> - <Nullable>enable</Nullable> - <TargetFrameworks>netcoreapp3.0;netcoreapp3.1;net5.0;net6.0;net7.0;net8.0;net9.0</TargetFrameworks> <PackageRequireLicenseAcceptance>false</PackageRequireLicenseAcceptance> <GeneratePackageOnBuild>false</GeneratePackageOnBuild> </PropertyGroup>If the common props file doesn't include all the required target frameworks for this specific project, you might need to extend them:
<PropertyGroup> <TargetFrameworks>$(TargetFrameworks);netcoreapp3.0;netcoreapp3.1;net5.0;net7.0</TargetFrameworks> </PropertyGroup>
🏁 Script executed:
#!/bin/bash # Check the content of the common props file cat props/WebApiClientCore.Common.propsLength of output: 897
Import common props and explicitly override TargetFrameworks
The shared props file (
props/WebApiClientCore.Common.props) brings inNullable,GenerateDocumentationFile,LangVersionand a default set of TFMs (netstandard2.1;net5.0;net8.0;net9.0), which aren’t valid for an EXE web project. To keep the common settings but ensure the correct frameworks:• In
App/App.csproj, immediately after the<Project>element, add:<Import Project="..\props\WebApiClientCore.Common.props" />• Remove these from the existing
<PropertyGroup>(they’re now inherited):
<Nullable>enable</Nullable><TargetFrameworks>…</TargetFrameworks>• Add a new
<PropertyGroup>to fully overrideTargetFrameworksfor this executable:<PropertyGroup> <TargetFrameworks>netcoreapp3.0;netcoreapp3.1;net5.0;net6.0;net7.0;net8.0;net9.0</TargetFrameworks> </PropertyGroup>This preserves all common settings while preventing
netstandard2.1from being applied to an EXE.
♻️ Duplicate comments (3)
WebApiClientCore.Abstractions/WebApiClientCore.Abstractions.csproj (1)
3-5: The same validation for theImportofWebApiClientCore.Common.propsand theIsAotCompatibleproperty applies here. Ensure the props file contains those definitions to avoid any build regressions.WebApiClientCore.Analyzers/WebApiClientCore.Analyzers.csproj (1)
3-3: Ensure theImportof../props/WebApiClientCore.Common.propsstays consistent with other projects and that the shared props file includes all required build settings.WebApiClientCore/WebApiClientCore.csproj (1)
2-5: The import ofWebApiClientCore.Common.propsand<IsAotCompatible>reference follows the established pattern. Ensure that the common props file indeed defines all necessary shared properties to avoid inadvertent omissions.
🧹 Nitpick comments (8)
WebApiClientCore.Analyzers/Providers/RefParameterDiagnosticProvider.cs (1)
13-18: Fix XML documentation commentThere's a documentation issue with nested
<summary>tags that should be fixed./// <summary> -/// /// <summary> /// 获取诊断描述 /// </summary> -/// </summary>WebApiClientCore.OpenApi.SourceGenerator/WebApiClientCore.OpenApi.SourceGenerator.csproj (1)
21-23: Fix indentation inconsistency and verify package versionsThe added package references use spaces for indentation while the rest of the file uses tabs. Also, these packages are being added to address potential security vulnerabilities:
- System.Net.Http 4.3.4 fixes CVE-2018-8292 and other vulnerabilities
- System.Text.RegularExpressions 4.3.1 addresses regex DoS vulnerabilities
- Newtonsoft.Json 13.0.1 addresses serialization vulnerabilities
- <PackageReference Include="Newtonsoft.Json" Version="13.0.1" /> - <PackageReference Include="System.Net.Http" Version="4.3.4" /> - <PackageReference Include="System.Text.RegularExpressions" Version="4.3.1" /> + <PackageReference Include="Newtonsoft.Json" Version="13.0.1" /> + <PackageReference Include="System.Net.Http" Version="4.3.4" /> + <PackageReference Include="System.Text.RegularExpressions" Version="4.3.1" />WebApiClientCore.Test/Implementations/Tasks/ActionRetryTaskTest.cs (1)
11-11: Improved nullability consistencyThe changes correctly update
ResultApiTask<T>to inherit fromTaskBase<T?>and returnTask<T?>fromInvokeAsync(), making the nullability consistent with the existing nullableResultproperty.Consider also updating
NotImplementedApiTask<T>for consistency, unless the difference in nullability handling is intentional for testing purposes.Also applies to: 15-15
props/WebApiClientCore.Common.props (1)
8-14: Simplify AOT compatibility settingsThe AOT compatibility settings could be simplified by removing redundant conditions:
<PropertyGroup> - <WebApiClientCoreIsAotCompatible>false</WebApiClientCoreIsAotCompatible> - <WebApiClientCoreIsAotCompatible Condition="'$(TargetFramework)' == 'netstandard2.1'">false</WebApiClientCoreIsAotCompatible> - <WebApiClientCoreIsAotCompatible Condition="'$(TargetFramework)' == 'net5.0'">false</WebApiClientCoreIsAotCompatible> + <WebApiClientCoreIsAotCompatible Condition="'$(TargetFramework)' == 'net8.0' Or '$(TargetFramework)' == 'net9.0'">true</WebApiClientCoreIsAotCompatible> + <WebApiClientCoreIsAotCompatible Condition="'$(TargetFramework)' != 'net8.0' And '$(TargetFramework)' != 'net9.0'">false</WebApiClientCoreIsAotCompatible> <WebApiClientCoreIsAotCompatible Condition="'$(TargetFramework)' == 'net8.0'">true</WebApiClientCoreIsAotCompatible> <WebApiClientCoreIsAotCompatible Condition="'$(TargetFramework)' == 'net9.0'">true</WebApiClientCoreIsAotCompatible> </PropertyGroup>Or even more simply:
<PropertyGroup> - <WebApiClientCoreIsAotCompatible>false</WebApiClientCoreIsAotCompatible> - <WebApiClientCoreIsAotCompatible Condition="'$(TargetFramework)' == 'netstandard2.1'">false</WebApiClientCoreIsAotCompatible> - <WebApiClientCoreIsAotCompatible Condition="'$(TargetFramework)' == 'net5.0'">false</WebApiClientCoreIsAotCompatible> - <WebApiClientCoreIsAotCompatible Condition="'$(TargetFramework)' == 'net8.0'">true</WebApiClientCoreIsAotCompatible> - <WebApiClientCoreIsAotCompatible Condition="'$(TargetFramework)' == 'net9.0'">true</WebApiClientCoreIsAotCompatible> + <WebApiClientCoreIsAotCompatible>$([System.String]::Equals('$(TargetFramework)', 'net8.0') Or [System.String]::Equals('$(TargetFramework)', 'net9.0'))</WebApiClientCoreIsAotCompatible> </PropertyGroup>WebApiClientCore.Analyzers/WebApiClientCore.Analyzers.csproj (1)
12-15: Unify PackageReference formatting.
The Roslyn analyzerPackageReferenceentries now span two lines for readability. To maintain consistency across all.csprojfiles, consider adopting a uniform style (either single-line or multi-line).-<PackageReference Include="Microsoft.CodeAnalysis.CSharp" Version="3.8.0" - PrivateAssets="all" /> +<PackageReference Include="Microsoft.CodeAnalysis.CSharp" + Version="3.8.0" + PrivateAssets="all" />WebApiClientCore/WebApiClientCore.csproj (3)
17-18: Centralize repetitive package versions.
TheMicrosoft.Extensions.Options.ConfigurationExtensionsreference is repeated with different version strings across target frameworks. To simplify future upgrades and avoid drift, consider defining these version numbers as MSBuild properties inWebApiClientCore.Common.propsand referencing them here:<PropertyGroup> <OptionsCfgExt_Version_3_0>3.0.0</OptionsCfgExt_Version_5_0>5.0.0</OptionsCfgExt_Version_8_0>8.0.0</OptionsCfgExt_Version_9_0>9.0.0</OptionsCfgExt_Version> </PropertyGroup> ... <PackageReference Include="Microsoft.Extensions.Options.ConfigurationExtensions" Version="$(OptionsCfgExt_Version)" />This DRYs up the version management.
Also applies to: 24-25, 31-32, 36-39
43-46: Streamline project reference formatting.
The<ProjectReference>elements are split across lines. For clarity and consistency, inline short references or adopt a uniform multi-line pattern. Example:-<ProjectReference - Include="..\WebApiClientCore.Abstractions\WebApiClientCore.Abstractions.csproj" /> +<ProjectReference Include="..\WebApiClientCore.Abstractions\WebApiClientCore.Abstractions.csproj" />
63-67: Refine comment and path separators.
- The XML comment for the analyzers path spans multiple lines; consider a single-line description like
<!-- Pack Roslyn analyzers into NuGet -->.- The
<None Include>path uses backslashes (\). For cross-platform MSBuild compatibility, it’s recommended to use forward slashes (/).
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (16)
App/App.csproj(1 hunks)WebApiClientCore.Abstractions/WebApiClientCore.Abstractions.csproj(2 hunks)WebApiClientCore.Analyzers/Providers/RefParameterDiagnosticProvider.cs(1 hunks)WebApiClientCore.Analyzers/SourceGenerator/HttpApiProxyClass.cs(1 hunks)WebApiClientCore.Analyzers/WebApiClientCore.Analyzers.csproj(2 hunks)WebApiClientCore.Extensions.JsonRpc/WebApiClientCore.Extensions.JsonRpc.csproj(1 hunks)WebApiClientCore.Extensions.NewtonsoftJson/WebApiClientCore.Extensions.NewtonsoftJson.csproj(1 hunks)WebApiClientCore.Extensions.OAuths/WebApiClientCore.Extensions.OAuths.csproj(2 hunks)WebApiClientCore.Extensions.SourceGenerator/WebApiClientCore.Extensions.SourceGenerator.csproj(1 hunks)WebApiClientCore.OpenApi.SourceGenerator/WebApiClientCore.OpenApi.SourceGenerator.csproj(2 hunks)WebApiClientCore.Test/Implementations/Tasks/ActionRetryTaskTest.cs(1 hunks)WebApiClientCore.Test/WebApiClientCore.Test.csproj(1 hunks)WebApiClientCore/DependencyInjection/NamedHttpApiExtensions.cs(2 hunks)WebApiClientCore/WebApiClientCore.csproj(2 hunks)props/WebApiClientCore.Common.props(1 hunks)props/WebApiClientCore.Extensions.Common.props(1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (2)
WebApiClientCore.Analyzers/SourceGenerator/HttpApiProxyClass.cs (1)
WebApiClientCore/Implementations/SourceGeneratorHttpApiActivator.cs (2)
Equals(146-165)Equals(168-171)
WebApiClientCore.Test/Implementations/Tasks/ActionRetryTaskTest.cs (1)
WebApiClientCore/Implementations/Tasks/TaskBase.cs (2)
TaskBase(10-36)Task(35-35)
🔇 Additional comments (16)
props/WebApiClientCore.Extensions.Common.props (1)
1-7: Good practice centralizing common build propertiesCreating a shared properties file for extension projects helps maintain consistency across the codebase and follows the DRY (Don't Repeat Yourself) principle. The properties defined here (nullable references, .NET Standard 2.1 target, and XML documentation generation) are appropriate for a library project.
WebApiClientCore.Analyzers/Providers/RefParameterDiagnosticProvider.cs (1)
53-53: Improved value type comparisonThe change from
modifier != nulltomodifier != defaultis appropriate sinceSyntaxTokenis a struct (value type). Usingdefaultcomparison is the idiomatic way to check for empty/uninitialized value types in C#.WebApiClientCore.Extensions.SourceGenerator/WebApiClientCore.Extensions.SourceGenerator.csproj (1)
2-3: Good practice importing common propertiesImporting the centralized properties file removes duplication and ensures consistent configuration across extension projects. This follows the DRY principle and makes future maintenance easier.
WebApiClientCore.Extensions.JsonRpc/WebApiClientCore.Extensions.JsonRpc.csproj (1)
3-3: Good practice importing common propertiesImporting the centralized properties file removes duplication and ensures consistent configuration across extension projects. This follows the DRY principle and makes future maintenance easier.
WebApiClientCore.Extensions.NewtonsoftJson/WebApiClientCore.Extensions.NewtonsoftJson.csproj (1)
3-3: Good refactoring to centralize common build propertiesMoving common build properties to a shared props file follows the DRY principle and improves maintainability. This change makes it easier to ensure consistent configuration across extension projects.
WebApiClientCore.OpenApi.SourceGenerator/WebApiClientCore.OpenApi.SourceGenerator.csproj (1)
6-6: Good addition of .NET 9.0 target frameworkAdding support for
net9.0ensures the project stays current with the latest framework. This aligns with the PR objective of updating target frameworks across the solution.props/WebApiClientCore.Common.props (1)
1-7: Excellent centralization of common build propertiesCreating this common props file is a great approach to standardize build configurations across multiple projects. It ensures consistency for nullable reference types, documentation generation, target frameworks, and language version settings.
WebApiClientCore/DependencyInjection/NamedHttpApiExtensions.cs (1)
41-45: LGTM! Good handling of nullable reference typeThe addition of the explicit null check for the
registrationobject improves null safety and prevents potentialNullReferenceExceptionat runtime.WebApiClientCore.Analyzers/SourceGenerator/HttpApiProxyClass.cs (1)
169-183: LGTM! Proper null parameter handling with cross-framework supportThe updated method signature now correctly accepts nullable parameters, and the implementation properly handles nulls with framework-specific approaches. Using
ArgumentNullException.ThrowIfNullfor .NET 8.0+ and explicit checks for earlier versions is an excellent practice.WebApiClientCore.Test/WebApiClientCore.Test.csproj (1)
4-4: LGTM! Added support for .NET 9.0Adding the .NET 9.0 target framework ensures the tests will run on the latest framework version, which is good for forward compatibility.
App/App.csproj (1)
6-6: LGTM! Added support for .NET 9.0Adding the .NET 9.0 target framework ensures the application can run on the latest framework version, which is good for forward compatibility.
WebApiClientCore.Extensions.OAuths/WebApiClientCore.Extensions.OAuths.csproj (2)
17-17: No action needed on closing tag.
The</Project>closing tag is correct and well-formed.
3-5:✅ Verification successful
Verify common props import and AOT compatibility property.
Confirm that../props/WebApiClientCore.Common.propscorrectly definesWebApiClientCoreIsAotCompatiblealong with other expected settings (e.g.,TargetFrameworks,Nullable,GenerateDocumentationFile). Missing definitions here will cause build failures.
🏁 Script executed:
#!/bin/bash # Check that the AOT compatibility property is defined in the common props file rg "WebApiClientCoreIsAotCompatible" -n props/WebApiClientCore.Common.propsLength of output: 650
🏁 Script executed:
#!/bin/bash # Verify that TargetFrameworks, Nullable, and GenerateDocumentationFile are defined in the common props file rg -n "<TargetFrameworks>" props/WebApiClientCore.Common.props rg -n "<Nullable>" props/WebApiClientCore.Common.props rg -n "<GenerateDocumentationFile>" props/WebApiClientCore.Common.propsLength of output: 368
Common props definitions validated
All required settings are present inprops/WebApiClientCore.Common.props:
WebApiClientCoreIsAotCompatibleis defined for each target framework.TargetFrameworksincludesnetstandard2.1;net5.0;net8.0;net9.0.Nullableis set toenable.GenerateDocumentationFileis set toTrue.WebApiClientCore.Abstractions/WebApiClientCore.Abstractions.csproj (1)
23-23: No action needed on closing tag.
The</Project>closing tag is correct.WebApiClientCore.Analyzers/WebApiClientCore.Analyzers.csproj (1)
39-39: No action needed on closing tag.
The</Project>closing tag is correctly positioned.WebApiClientCore/WebApiClientCore.csproj (1)
69-69: No action needed on closing tag.
The final</Project>tag is correct.
| var registration = (NameTypeRegistration?)descriptor.ImplementationInstance; | ||
| registration![name] = httpApiType; |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider replacing null-forgiving operator with explicit null check
The null-forgiving operator (!) on line 25 suppresses the nullable warning without actually verifying if registration is null. If registration is null at runtime, this will cause a NullReferenceException.
-var registration = (NameTypeRegistration?)descriptor.ImplementationInstance;
-registration![name] = httpApiType;
+var registration = (NameTypeRegistration?)descriptor.ImplementationInstance;
+if (registration == null)
+{
+ throw new InvalidOperationException($"The {nameof(NameTypeRegistration)} instance was not properly initialized.");
+}
+registration[name] = httpApiType;| <PackageReference Include="System.Text.Encodings.Web" Version="4.7.2" /> | ||
| </ItemGroup> |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify new package reference version.
Ensure that System.Text.Encodings.Web version 4.7.2 is intended for your netstandard2.1 target and that no known vulnerabilities affect it. If this dependency is not part of your public API surface, consider adding <PrivateAssets>all</PrivateAssets>.
🌐 Web query:
What is the latest stable version of the NuGet package System.Text.Encodings.Web, and are there any known security advisories for version 4.7.2?
💡 Result:
Latest Stable Version of System.Text.Encodings.Web
The latest stable version of the NuGet package System.Text.Encodings.Web as of April 2025 is 9.0.4[1]. This version provides important types for securely encoding and escaping strings for use in JavaScript, HTML, and URLs.
Security Advisories for Version 4.7.2
Yes, there are known security advisories affecting System.Text.Encodings.Web version 4.7.2. Specifically, this version is vulnerable to a remote code execution vulnerability (CVE-2021-26701), which affects several versions of the package, including 4.6.0 through 4.7.2 and some in the 5.x series[6]. The vulnerability concerns how text encoding is performed and can impact any .NET 5, .NET Core, or .NET Framework application using these versions of the package.
Details:
- Vulnerability: Remote code execution
- CVE: CVE-2021-26701
- Affected Versions: 4.6.0 – 4.7.2, 5.0.0, 5.0.1
- Mitigation: Upgrade to a newer, patched version. Microsoft recommends updating the package and redeploying your application to ensure security[6].
- No further vulnerabilities are listed specifically against version 4.7.2 in some other vulnerability databases, but CVE-2021-26701 is confirmed and relevant[4][6].
Summary Table
| Version | Latest Stable | Known Security Advisory for 4.7.2? |
|---|---|---|
| System.Text.Encodings.Web | 9.0.4 | Yes, CVE-2021-26701 (Remote Code Execution)[6] |
Recommendation:
If you are using System.Text.Encodings.Web version 4.7.2, you should upgrade to the latest stable version (currently 9.0.4) to address security concerns[1][6].
For further details or to verify the latest version, consult the official NuGet package page for System.Text.Encodings.Web[1].
Citations:
- 1: https://www.nuget.org/packages/system.text.encodings.web/
- 2: https://learn.microsoft.com/en-us/dotnet/api/system.text.encodings.web?view=net-9.0
- 3: https://www.nuget.org/packages/System.Text.Encodings.Web/8.0.0
- 4: https://www.meterian.io/components/dotnet/System.Text.Encodings.Web/
- 5: Using latest .NET Core 3.0 packages with Azure Functions v2 (like System.Text.Encodings.Web) causes "Method not found" issue due to assembly version mismatch Azure/azure-functions-host#5031
- 6: Microsoft Security Advisory CVE-2021-26701 | .NET Core Remote Code Execution Vulnerability dotnet/runtime#49377
- 7: https://learn.microsoft.com/en-us/dotnet/framework/whats-new/
- 8: https://learn.microsoft.com/en-us/dotnet/api/system.text.encodings.web.javascriptencoder?view=net-9.0
- 9: https://advisories.gitlab.com/pkg/nuget/system.text.encodings.web/
- 10: The Nuget package for System.Text.Encodings.Web v4.7.2 has the strong name of 4.0.5.1 dotnet/runtime#99326
Upgrade System.Text.Encodings.Web to a patched version
Version 4.7.2 is affected by CVE-2021-26701 (remote code execution). The latest stable release is 9.0.4. Please update and, if this dependency isn’t exposed in your public API, mark it as private.
• In WebApiClientCore.Abstractions/WebApiClientCore.Abstractions.csproj, change:
- <PackageReference Include="System.Text.Encodings.Web" Version="4.7.2" />
+ <PackageReference Include="System.Text.Encodings.Web" Version="9.0.4">
+ <PrivateAssets>all</PrivateAssets>
+ </PackageReference>📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| <PackageReference Include="System.Text.Encodings.Web" Version="4.7.2" /> | |
| </ItemGroup> | |
| <PackageReference Include="System.Text.Encodings.Web" Version="9.0.4"> | |
| <PrivateAssets>all</PrivateAssets> | |
| </PackageReference> | |
| </ItemGroup> |
| <EmbeddedResource Update="Resx.en-US.resx"> | ||
| <Generator>ResXFileCodeGenerator</Generator> | ||
| <LastGenOutput>Resx.Designer.cs</LastGenOutput> | ||
| <DependentUpon>Resx.resx</DependentUpon> | ||
| </EmbeddedResource> |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify en-US resource embedding.
A new <EmbeddedResource> entry for Resx.en-US.resx was added. Please confirm that Resx.en-US.resx exists in the project directory and that the <DependentUpon> relationship correctly ties it to Resx.resx so the designer file is generated as expected.
🏁 Script executed:
#!/bin/bash
# Verify the localized resource file exists alongside Resx.resx
test -f "$(dirname "$0")/Resx.en-US.resx" && echo "Resx.en-US.resx found." || echo "ERROR: Resx.en-US.resx missing."Length of output: 173
Missing Resx.en-US.resx resource file
The <EmbeddedResource> entry for Resx.en-US.resx isn’t resolvable—no such file exists alongside Resx.resx. Please add Resx.en-US.resx to the project directory or remove/update this entry if the localized resource isn’t needed.
• File to update:
- WebApiClientCore.Analyzers/WebApiClientCore.Analyzers.csproj (lines 32–36)
• Actions:
- Add
WebApiClientCore.Analyzers/Resx.en-US.resxnext toResx.resx - OR remove or adjust the
<EmbeddedResource>block if you don’t intend to embed an en-US resource
- <EmbeddedResource Update="Resx.en-US.resx">
+ <EmbeddedResource Include="Resx.en-US.resx">
<Generator>ResXFileCodeGenerator</Generator>
<LastGenOutput>Resx.Designer.cs</LastGenOutput>
<DependentUpon>Resx.resx</DependentUpon>
</EmbeddedResource>Committable suggestion skipped: line range outside the PR's diff.
Summary by CodeRabbit
New Features
Refactor
Bug Fixes