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

[BodrickLight]

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]

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]

For me I feel that we should offer a dotnet tool distributed via Nuget which we call AsyncAPI.Saunter.Generation.Tool or Cli (#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 (#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.