Split package

[imperugo]

Hi Steve,
first of all thanks for this cool library.
Right now the package has the following dependencies

• Microsoft.AspNetCore.Http.Abstractions (>= 2.1.1)
• Microsoft.Extensions.Http (>= 2.1.1)
• Microsoft.Extensions.Logging.Abstractions (>= 2.1.1)
• Microsoft.Extensions.Options (>= 2.1.1)

As far as I understood the first one is used only for the middleware.
In my project I've shared packages that will be used in a web scenario and also in a not web scenario, basically these packages are using HTTP Client to make api requests and, thanks to this library, they are using AddCorrelationIdForwarding.

The point here is that, in a not web scenario, I don't need Microsoft.AspNetCore.Http.Abstractions package and I don't want to bring it in.

Does it make sense to you to split it into two packages, one with the middleware and the other one with the other things?

[stevejgordon]

Hi @imperugo,

Thanks for raising this issue for discussion. To be honest, I never imagined many scenarios where this would be used outside of ASP.NET Core. The original feature was the piece to grab the Correlation ID from the incoming HTTP request.

For the services I've written that are not ASP.NET Core (workers etc.) I've basically used a small custom DelegatingHandler directly to add a user agent and generate a correlation ID.

How are you generating the ID? Are you relying on the ICorrelationContextAccessor anywhere?

I'll mark this under consideration, as honestly, splitting into extra packages feels like it adds more maintenance burden for little relative gain. For such a simple library, having to explain which package developers want/need etc. might make it more confusing overall. That said, the packing of the ASP.NET dependencies etc has changes somewhat since I produced this and may warrant some changes here.

Are you able to provide examples of which pieces you use currently and how they are applied?

Meanwhile, for others viewing this, please up vote if you have similar use cases where removing the middleware dependency would be helpful.

[MatthewLymer]

Not sure how to upvote, but I thumbs up'ed it.

I have the same use-case as described, I have some class-libraries that are used in both a HttpClient capacity (used by asp.net webapp and a kubernetes cron job), and sometimes I use it in cases not tied to HttpClient when inserting into a database.