Circular dependency issue with nswag generated client project

Question

I have an ASP.NET Core 7 Web API project that uses the Swashbuckle.AspNetCore package. My goal is to generate the client classes for that service using its OpenAPI specification JSON file and publish that as a client nuget package.

The way I'm doing it right now is as follows:

1. A custom target is defined in the Web API project to essentially run dotnet swagger tofile to spit out a swagger.json file (this is the OpenAPI specification).
2. A second project, which is essentially an empty project, contains a custom target to run nswag run to generate client code from the previous swagger.json file. This project has a ProjectReference pointing to the first project to force it to run first (so I always have an updated swagger.json). It also uses PrivateAssets="all" to avoid the Web API assembly from being included in the nuget package generated from it)

Here's the part where it gets complicated. The DTOs I use in the controllers are shared with the client library. I tell nswag to NOT generate the DTOs, because for various reasons, I need to share the hand-written DTOs with clients. To avoid having a circular reference between the Web API project and the Client projects, I have created a third "Models" project to contain those DTO objects. That way the dependencies look like this:

• Web API -> Models
• Client -> Models, Web API

Unfortunately, the default behavior for dotnet pack is to create a package for the Models project. However, I want the Models assembly to be packaged in with the Client package (so it has two DLLs) and also inherit the package dependencies in the final nuspec. All the research I have done says this isn't possible, or at the very least, isn't easy.

At this point I feel like I'm headed down the wrong path so I want to reset and see what a better approach would be. The goal I'm actually trying to solve here is a way to share the models between the Web API and Client projects without creating a circular dependency. Maybe that means the way I have the custom targets set up needs to change, but I'm not sure what the best approach is.

What is a better way to set up these dependencies and this code generation workflow so that I can have a single Client nuget package with both the models and the generated client classes?

Answer 1

Well, based on your comment, I am considering this answer as an extended part of my comment.

What is a better way to set up these dependencies and this code generation workflow so that I can have a single Client nuget package with both the models and the generated client classes?

If you want to keep the DTOs separate from the Web API project, consider using a Shared Project. Shared Projects won't produce a DLL; instead, they are compiled directly into referencing projects, thus, you won't face the packaging issue. Another point is that, Consider creating two separate NuGet packages: one for the shared Models and another for the generated client code. This way, consumers can choose whether they want just the models or both the models and the client code.

How does one create a Shared Project? I have never heard of these before. And I don't recall seeing it in the New Project templates in Jetbrains Ride

I am not familiar with Jetbrains Rider but I can guide you using visual studio 2022 how to do that.

Please follow below steps in order to create class library project in visual studio 2022.

Complete output:

Note: Please refer to this official document if need more specification regarding how to use ASP.NET Core class library