Hangfire: .NETCore 2.0 Console. app.UseHangfireDashboard is not available

[ghost]

I created a new .net core 2.0 console project.

using Hangfire;
using Microsoft.Owin;
using Owin;

[assembly: OwinStartup(typeof(Test.WorkerHost))]
namespace Test.worker
{
    public class WorkerHost
    {
        public void Configuration(IAppBuilder app)
        {
            app.UseHangfireDashboard(); // This is not available
        }
    }
}

All examples mention to configure hangfire like above but I dont get those extension methods. Already gone through
http://docs.hangfire.io/en/latest/configuration/using-dashboard.html

https://stackoverflow.com/questions/49623349/how-to-configure-hangfire-net-in-net-core-console-application

Any idea?

[ghost]

Alright, after trial and error. I got it working by adding Hangfire.AspnetCore nuget and using IApplicationBuilder instead of IAppBuilder.

[pieceofsummer]

Since the issue is resolved, I'm closing it.

On a side note, OWIN sure may be used with .NET Core applications, but it doesn't bring any benefits. Neither .NETStandard version of Hangfire includes any OWIN-related code.

[ghost]

It'd be nice to have a documentation on how to configure hangfire dashboard in .net core console app? The one mentioned below is only if you host in asp.net web app and doesn't work in console app. http://docs.hangfire.io/en/latest/configuration/using-dashboard.html

[pieceofsummer]

Yeah, the documentation lacks information about .NET Core :(

If you want to host dashboard in a .NET Core app, you better start with .NET Core web app template (it is pretty much the same as a .NET Core console app, but already contains initialization code in Main and provides a Startup.cs file). After the project is created, you should add Hangfire.Core, Hangfire.AspNetCore and storage (e.g. Hangfire.SqlServer) packages.

Then you just call services.AddHangfire in ConfigureServices and perform configuration in a callback:
```c#
public void ConfigureServices(IServiceCollection services)
{
// ... other required services ...

services.AddHangfire(configuration =>
{
    // Do pretty much the same as you'd do with 
    // GlobalConfiguration.Configuration in classic .NET

    // NOTE: logger and activator would be configured automatically, 
    // and in most cases you don't need to configure those.

    configuration.UseSqlServerStorage(...);

    // ... maybe something else, e.g. configuration.UseConsole()
});

}

Then add the Hangfire dashboard to the app pipeline in `Configure`:
```c#
public void Configure(IApplicationBuilder app, IRecurringJobManager recurringJobManager)
{
    // ... previous pipeline stages, e.g. app.UseAuthentication()

    app.UseHangfireDashboard(...);

   // ... next pipeline stages, e.g. app.UseMvc()

   // then you may configure your recurring jobs here:
   recurringJobManager.AddOrUpdate(...);
}

Hope this helps.

[pedrosimoes79]

@pieceofsummer: I succeeded on creating a C# .NET Core console app including TopShelf by following your guide. Thks 👍

[ppumkin]

🤔 It would be better to let the console application act as a server node.

You may want to spin up more nodes and that means you have all the OWIN or Http stuff included and started for each node. This can be problematic if you trying to optimise memory consumption. Furthermore if you going to dockerise or host nodes on various servers you need to keep a list of all the ip's, hosts and ports - times a hundred or thousand = ☠

✔ Instead create a Front End server

Create a Web Project or a shell (as demonstrated above) of one and configure everything as normal EXCEPT do not add services.AddHangfireServer

There is no compelling reason for the front end to process jobs. If you want to add a node on the same server just to start off, that is going to better in longrun as you can then add more else where and simply remove the original one.

😃 The advantages are

• Separation of concern (Single Responsibility Principle)
• The Web application can be hosted once
  
  
  
  • It can be configured to show more than one server centrally by means of multiple SQL Connections
  
  
  • This means jobs can be managed for any configured server in one, easily accessible place
  
  
• Nodes become lightweight and simple
  
  
  
  • can be scaled up efficiently
  
  
  • can run anywhere
  
  
  • only responsible for executing jobs it knows about