Microsoft.AspNetCore.App dependency about coravel HOT 12 CLOSED

I can only agree with the other participants here and your solution. Queue-bound microservices e.g. do not rely on ASP.NET Core but for example its nice IHostBuilder component instead of the IWebHostBuilder interface. Also there is no Startup class in that case.
Other projects like Serilog utilize additional NuGet packages to create a more native feeling for dedicated frameworks like ASP.NET Core Serilog.AspNetCore.

Thanks for your work.

from coravel.

Great - thanks @tthiery and @IonRobu for the awesome feedback! I'll aim to publish the changes later today 👍

from coravel.

This might also fix another concern I'm having with another piece I'm building...

Thanks for the feedback @IonRobu !

It's great having people able to give some more insight / alternative scenarios.

from coravel.

Maybe IApplicationBuilder extension methods from Registration classes should be rewritten as IServiceCollection or IServiceProvider extensions methods?

from coravel.

I'll do some investigation and get back to you. My initial thought is that the Application piece is needed due to the way the internal services are tied right into the DI container, which let's Coravel use DI etc.

I'll let you know.

P.S. any specific feature that you need in a shared project?

Thanks!

from coravel.

The scenario is perfect in asp.net core applications, but the middle ("business") layer referring the Coravel package may be also used in non-web scenario, so I think the Microsoft.AspNetCore.App reference should not be there.

from coravel.

What pieces of Coravel would you use in that scenario?

from coravel.

For the moment, I use cache, but I intend to integrate also scheduler, queueing, events

from coravel.

I think converting to IServiceProvider might be promising. I def cannot use IServiceCollection since Coravel needs access to the provider to "rig" stuff up.

I'll let you know when I've got some more progress made 👍

from coravel.

Playing around right now, here's the quick and dirty version.I removed the non-abstract dep. on AspNetCore and kept the very specific pieces I need - but using the appropriate "abstractions" reference. Here's what that would look like:

    <PackageReference Include="Microsoft.Extensions.Caching.Memory" Version="2.1.0"/>
    <PackageReference Include="Microsoft.Extensions.Logging.Abstractions" Version="2.1.0"/>
    <PackageReference Include="Microsoft.Extensions.Hosting.Abstractions" Version="2.1.0"/>

Already, build times are extremely faster too since it's not bringing in that entire ecosystem.

So either way this is promising 👍

What do you think about these dependencies?

from coravel.

Playing around right now, here's the quick and dirty version.I removed the non-abstract dep. on AspNetCore and kept the very specific pieces I need - but using the appropriate "abstractions" reference. Here's what that would look like:

    <PackageReference Include="Microsoft.Extensions.Caching.Memory" Version="2.1.0"/>
    <PackageReference Include="Microsoft.Extensions.Logging.Abstractions" Version="2.1.0"/>
    <PackageReference Include="Microsoft.Extensions.Hosting.Abstractions" Version="2.1.0"/>

Already, build times are extremely faster too since it's not bringing in that entire ecosystem.

So either way this is promising

What do you think about these dependencies?

I think is very good. Also, @tthiery's proposed pattern is a good one - having framework-specific "extension" packages

from coravel.

Coravel nuget 1.9.0 should be available. Release Notes here

Thanks @tthiery and @IonRobu ! Let me know how things work out.

from coravel.