-
Notifications
You must be signed in to change notification settings - Fork 72
Fix: immichapi client generation #542
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
Conversation
📝 WalkthroughWalkthroughUpdated NSwag.ApiDescription.Client package from version 13.20.0 to 14.6.3 in central package management. Modified ImmichApi constructor to compute BaseUrl by concatenating the provided URL with "/api" instead of relying on a private field assignment. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related PRs
Suggested labels
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ 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. Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
Directory.Packages.propsImmichFrame.Core/Api/ImmichApi.cs
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Analyze (csharp)
🔇 Additional comments (1)
ImmichFrame.Core/Api/ImmichApi.cs (1)
5-10: Constructor change correctly implements NSwag 14.x compatibility.The change from assigning to a private
_baseUrlfield to setting theBaseUrlproperty aligns with NSwag 14.x generated code structure and resolves the Linux generation issue. No remaining references to the old_baseUrlfield exist, the constructor is being called correctly with the URL parameter, and the URL concatenation is straightforward with no double-slash issues detected.
| <PackageVersion Include="Moq" Version="4.20.72" /> | ||
| <PackageVersion Include="Newtonsoft.Json" Version="13.0.4" /> | ||
| <PackageVersion Include="NSwag.ApiDescription.Client" Version="13.20.0" /> | ||
| <PackageVersion Include="NSwag.ApiDescription.Client" Version="14.6.3" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
🌐 Web query:
NSwag.ApiDescription.Client version 14.6.3 release nuget
💡 Result:
NSwag.ApiDescription.Client version 14.6.3 is published on NuGet (published November 20, 2025). Install with:
- dotnet: dotnet add package NSwag.ApiDescription.Client --version 14.6.3
- PackageReference: .
Dependencies include Microsoft.Extensions.ApiDescription.Client (>= 8.0.14) and NSwag.MSBuild (>= 14.6.3). [1]
Sources: NuGet package page for NSwag.ApiDescription.Client 14.6.3. [1]
🌐 Web query:
NSwag 13 to 14 migration guide breaking changes
💡 Result:
Summary of key breaking changes when migrating NSwag v13 → v14 and recommended actions:
-
NJsonSchema / generator settings moved
- Generator-specific JSON/schema settings moved into a SchemaSettings property (NJsonSchema/NJsonSchema.Newtonsoft changes). Adjust code/config that previously set generator settings directly. [1][2]
-
nswag.json generation changed: only .csproj-based generation supported
- Reflection/assembly-based generation (typesToOpenApi, webApiToOpenApi) removed; only aspnetcore2openapi / .csproj OpenApiReference flows remain. If you used typesToOpenApi or WebApiToOpenApiCommand, switch to project-based generation (OpenApiReference in csproj) or use WebApiOpenApiDocumentGenerator programmatically. Many users reported breakage of prior csproj OpenApiReference usages — test your CI pipelines. [1][3]
-
Removed/renamed APIs and deprecated features removed
- Many previously-obsolete properties/methods were removed. Example: UseSwaggerUi3 renamed to UseSwaggerUi. Review compile errors and replace removed APIs per release notes. [1][2]
-
WebApiToOpenApiCommand removed
- Use WebApiOpenApiDocumentGenerator or a custom CLI that references the controllers project to generate OpenAPI without starting the app. [1]
-
Newtonsoft.Json requirement and JSON library split
- Requires Newtonsoft.Json >= 13.0.0.3. NJsonSchema moved many Newtonsoft-based components into NJsonSchema.NewtonsoftJson; NJsonSchema core contains System.Text.Json converters. If you relied on Newtonsoft-specific generators, add the NJsonSchema.NewtonsoftJson package and update serializer-related configuration. [1][2]
-
Target frameworks changed
- v14 targets: .NET Standard 2.0, .NET 4.6.2, .NET Core 3.1, .NET 5, .NET 7+ (and later v14 releases add NET8/NET9/NET10 support and drop some older targets). Confirm your target framework compatibility and update projects/CI accordingly. [1][2][3]
-
Template engine and codegen changes
- Migration from DotLiquid → Fluid and other template/runtime generator changes can affect custom templates; update templates for Fluid or switch to supported template approach. [4][2]
-
MSBuild/OpenApiReference & Microsoft package ecosystem changes (related)
- Microsoft has been deprecating the Microsoft.Extensions.ApiDescription.Client / dotnet openapi workflow; recommended workflow is generator-specific tooling (npx/dotnet tool NSwag, Kiota, etc.). If you relied on MSBuild middle-layer, migrate to NSwag tooling or commit generated clients. [4]
Recommended steps to migrate
- Read v14 release notes and the v14 preview/breaking-changes thread to identify removals that affect you. [1][2]
- Update dependencies: NSwag v14 packages, NJsonSchema (and NJsonSchema.NewtonsoftJson if needed), and Newtonsoft.Json >= 13.0.0.3. [1][2]
- Replace assembly/reflection-based generation flows with .csproj-based generation or programmatic WebApiOpenApiDocumentGenerator. Test OpenApiReference entries in csproj and CI. [1][3]
- Search/replace removed APIs (UseSwaggerUi3 → UseSwaggerUi, etc.) and adjust settings moved under SchemaSettings.
- If you used custom templates, migrate them to Fluid or the new templating approach.
- Run generator locally and in CI; inspect generated schemas/clients for behavioral changes, particularly around polymorphism/Json library differences.
Primary references
- NSwag v14 preview & breaking changes (issue and description). [1]
- NSwag releases/changelog (v14.x release notes). [2]
- Reported migration issues (OpenApiReference / typesToOpenApi breakages). [3]
- Microsoft guidance on deprecation of ApiDescription Client / OpenApiReference workflows. [4]
If you want, I can:
- Scan your nswag.json / csproj and show exact changes to make.
- Produce a short checklist for updating CI pipelines.
🌐 Web query:
NSwag 14.6.3 security vulnerabilities advisories
💡 Result:
Short answer: I found no public security advisories or CVEs that list NSwag 14.6.3 itself as vulnerable. Current vulnerability databases (Snyk, ReversingLabs) report no known vulnerabilities for v14.6.3. [1][2]
Notes and related items to be aware of:
- Older NSwag/MSBuild releases have had reported vulnerabilities (e.g., issues reported against NSwag.MSBuild packages in the project issue tracker); verify you’re not using an older MSBuild package variant. [3]
- Separate .NET ecosystem advisories (for example CVE-2024-43485 for System.Text.Json) can affect projects that include vulnerable framework packages—check NSwag’s runtime/dependency versions in your environment. [4]
If you want, I can:
- scan a specific project (package-lock/NuGet) to show whether 14.6.3 or any vulnerable dependency is present, or
- monitor GitHub/OSV advisories for changes and notify you. Which would you prefer?
Sources:
[1] Snyk package page for nswag (latest version 14.6.3) — no known security issues.
[2] ReversingLabs / NuGet package assessment for NSwag.Generation 14.6.3 — no known vulnerabilities.
[3] GitHub issue discussing historical vulnerabilities in NSwag.MSBuild packages.
[4] Microsoft/GitHub advisory CVE-2024-43485 (System.Text.Json) — example of a .NET advisory to consider when auditing dependencies.
Verify that code changes address NSwag v14 breaking changes.
Version 14.6.3 (November 2025 release) is stable with no known security vulnerabilities. However, the upgrade from v13.20.0 introduces significant breaking changes that must be addressed:
- Assembly-based generation (typesToOpenApi, webApiToOpenApi) removed; migrate to .csproj-based OpenApiReference
- NJsonSchema/generator settings moved into SchemaSettings property
- Deprecated APIs removed (UseSwaggerUi3 → UseSwaggerUi, WebApiToOpenApiCommand removed)
- Template engine changed from DotLiquid to Fluid
- Requires Newtonsoft.Json >= 13.0.0.3
- Target framework support changed
Ensure the codebase has been updated to handle these breaking changes. Search for assembly-based generation patterns, custom templates, and deprecated API usage to confirm compatibility.
🤖 Prompt for AI Agents
In Directory.Packages.props around line 20 the NSwag.ApiDescription.Client
package is pinned to 14.6.3; you must verify the repo was migrated to address
NSwag v14 breaking changes — search the codebase for assembly-based generation
patterns (typesToOpenApi, webApiToOpenApi) and replace them with csproj
OpenApiReference entries, relocate any NJsonSchema/generator settings into
SchemaSettings, update deprecated API usages (UseSwaggerUi3 → UseSwaggerUi,
remove WebApiToOpenApiCommand usage), convert any DotLiquid templates to Fluid
or adjust template usage, ensure Newtonsoft.Json dependency is bumped to at
least 13.0.0.3, and confirm target framework compatibility; make the minimal
code/config edits (csproj OpenApiReference entries, settings renames, API call
updates, template conversions, package version bump) and run build/tests to
validate.
|
Weird, not sure how it worked before? |
I recently switched to Linux as my OS. When generating the OpenAPI client, I had some issues. I am not sure why this worked before on Windows (WSL).
Summary by CodeRabbit
Chores
Refactor
✏️ Tip: You can customize this high-level summary in your review settings.