search

asyncapi / saunter

Saunter is a code-first AsyncAPI documentation generator for dotnet.
https://www.asyncapi.com/
MIT License
195 stars 55 forks source link

Split document generation into a separate package to allow use on non-ASP.NET Core frameworks #136

Open BodrickLight opened 2 years ago

BodrickLight commented 2 years ago

I've been trying to get Saunter to work in a Microsoft.NET.Sdk.Worker console application which doesn't use the Microsoft.AspNetCore.App framework. I can apply the annotations to my source classes, and extract the AsyncApiOptions from the IServiceProvider from a tool in a similar way to Swashbuckle.AspNetCore.Cli, which means I can successfully generate an AsyncAPI document. However, when running the worker app after these changes, this results in a runtime exception: The framework 'Microsoft.AspNetCore.App', version '6.0.0' (x64) was not found..

It would be helpful if the classes responsible for the AsyncAPI document generation (which do not depend on ASP.NET Core) were separated out from the hosting configuration for the resulting file. By putting them in a separate NuGet package, it would allow consumers to reference that package directly, without having to add a runtime dependency on the ASP.NET Core framework.

m-wild commented 1 year ago

Yep this makes sense. It used to work with multitargeting netstandard2.0, but that has become difficult to manage. I will look to publish 2 separate nuget packages to accommodate this.

thompson-tomo commented 3 months ago

For me I feel that we should offer a dotnet tool distributed via Nuget which we call AsyncAPI.Saunter.Generation.Tool or Cli (https://github.com/asyncapi/saunter/issues/196) which would depend on a AsyncAPI.Saunter.Generation.Core package (this issue). This tool would accept in an argument which is the path to the reference doc.

At the same time we should offer a separate package AsyncAPI.Saunter.Generation.Build (https://github.com/asyncapi/saunter/issues/197) which also depends on the core & the difference is that the msbuild process would now generate in the bin folder each time a build occurs the spec file. For this option the build task would rely on csproj properties just like nuget packaging does.

Let's use this issue to focus on providing that core package hence the seperate issues and I can make use of the core package to save me time.