Split asp.net core package to support Windows Service hosting scenarios without use asp.net core assemblies

[danielmeza]

This can be simple done by creating a package only for configure the dependency services this way we can use hangfire server in a non web environment like console app or simply a windows service without use Microsoft.AspNetCore.* packages since there are not needed on those environments, those packages are needed only when we want use the dashboard.

The package name can be Hangfire.Extensions.DependencyInjection this to fit the .net core extension packages name convention. and the Hangfire.AspNetCore use that packages and expose all the necessary method for use the dashboard.

[pieceofsummer]

I believe it is already done in Hangfire.NetCore package.

[danielmeza]

@pieceofsummer yes it's, any doc on it, I see the name is too specific since its work also on .NET Framework and name indicate that only work on .net core

[pieceofsummer]

It uses the same sources as Hangfire.AspNetCore, except for dashboard-related implementations and IApplicationBuilder extension methods. That way it only references Microsoft.Extensions.* packages, so you can use it with non-web netstandard2.0 projects.

[danielmeza]

Good for doc! what about the specific name.

[pieceofsummer]

It is indeed for .net core only, as IHostedService is not supported on classic .net framework.

You can create console .net core apps from the very beginning. And .net core 3 now adds support for windows services as well.

[danielmeza]

I test the package using .NET Framework and it works ok, so the name is too specific for this version. And IHostedService is a .net standard api so it is supported on classic framework, the name should be less specific any way.

[pfeigl]

I'd like to stretch this topic a little further.

Please make it so, that every non-web related code lives in NetCore only and AspNetCore only adds the missing parts for web applications and internally again depends on NetCore

We are using Hangfire in multiple different projects and therefor wrote some shared libraries for default database configuration stuff and so on.

We are hosting the Hangfire servers as windows services (NetCore only) and only run the Dashboard and the Job-Registration within the web applications.

With this combination we frequently run into conflicts because the same extension methods are defined in two different assemblies.

How it should be in my opinion:

• All the IServiceCollection extensions should live in NetCore exclusively
• All the IApplicationBuilder extensions should live in the AspNetCore package and reference the NetCore package

Does this make sense. Am I missing anything?

[pfeigl]

This is btw how to fix it temporarily: https://stackoverflow.com/questions/33460667/how-to-use-extern-alias-with-nuget

[rklfss]

Stumbled upon this issue as well. We are separating Hangfire Server and Client. When using docker, it eventually requires mcr.microsoft.com/dotnet/aspnet:6.0 instead of mcr.microsoft.com/dotnet/runtime:6.0 as base image for the server, which makes no sense.

As I understand it, ASP.Net is only needed for the Dashboard.

Why not make a Hangfire.DependencyInjection lib for the IServiceCollection-Extensions and such (like other projects have) and a Hangfire.Dashboard lib?

[TraGicCode]

Stumbled upon this issue as well. We are separating Hangfire Server and Client. When using docker, it eventually requires mcr.microsoft.com/dotnet/aspnet:6.0 instead of mcr.microsoft.com/dotnet/runtime:6.0 as base image for the server, which makes no sense.

Same here. I'm also a bit surprised that this ticket has been open for so long :(. I would love to see it resolved in an upcoming release!

[odinserj]

Please use the Hangfire.NetCore package for newer .NET platforms integration without ASP.NET Core bits, and the Hangfire.AspNetCore package for full integration with the ASP.NET Core framework.

In Hangfire 1.7.X, these packages were implemented with the same types, but were detached from each other, making it more difficult to have referenced both in a solution. But with Hangfire 1.8.0 and above, Hangfire.AspNetCore references Hangfire.NetCore, and there are no problems with this anymore.