0

I'm trying to follow HangFire's documentation on how to setup IIS to always run and automatically startup hangfire on reboots, after configuring the IIS i've run into a problem, when my application tries to preload it will crash and stop the application pool, in windows server's event viwer the following exceptions are logged:

There was an error during processing of the managed application service auto-start for configuration path: 'MACHINE/WEBROOT/APPHOST/myApp/'. The error message returned is: 'An initialization error occurred while trying to preload an application.
    
    Exception: System.Web.HttpException
    
    Message: Could not load type 'myApp.MvcApplication'.

and

There was an error during processing of the managed application service auto-start for configuration path: 'MACHINE/WEBROOT/APPHOST/devfinance/'. The error message returned is: 'An initialization error occurred while trying to preload an application.

Exception: System.Web.HttpException

    Message: The CodeDom provider type "Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" could not be located. (E:\IIS-Applications\myApp\web.config line 437)

Both hangfire server and my application runs normally when run locally, the problem only happens on the IIS, my IIS version is 8, anyone ever had similar errors?

L4marr
  • 291
  • 2
  • 16
  • 1
    On our team, due to the difficulty of ensuring IIS is always running, we don't bother trying to actually run our jobs in an ASP.NET site. Instead, we put the Hangfire background job server (the part that actually runs the jobs) in a Windows Service (using [TopShelf](http://topshelf-project.com/) for .NET Framework apps). Then we host the Hangfire dashboard in an ASP.NET site in IIS. As long as they're pointing to the same storage, it's worked great for us. You might consider doing the same, as "always running IIS" has never worked great for us. – mason May 20 '22 at 23:20
  • Another nice advantage to the above is that you can individually scale your background job processing (the Windows Service) independently from your ASP.NET site. If scalability is something you need, that's a nice benefit. – mason May 20 '22 at 23:23
  • Have you see [this question](https://stackoverflow.com/questions/56937448/asp-net-codedom-provider-could-not-be-located-error)? – mason May 20 '22 at 23:30
  • @mason, when using hangfire server as a separate service do you have to maintain two codebases?, for example, when you change something in your web app do you have to duplicate that change in the hangfire service app?, i've searched for a guide on how to setup a service app for hangfire using topshelf but didnt found anything relevant. – L4marr May 25 '22 at 20:23
  • Yes and no. The signature for the job has to match, so that should be in an assembly both apps reference. We accomplish that by keeping them in the same solution and having both our web app and our Windows service app reference that class library. The web app doesn't need to reference the actual implementation, just the signature (interface) (assuming you're using a DI container). – mason May 25 '22 at 20:26
  • currently I am not using any DI/IoC in my application, if i were to simply make an new project for the topshelf service in my solution and refferece all my web app modules on it would it work? – L4marr May 26 '22 at 16:58
  • 2
    I would think so. I would personally try to put all the job logic in a class library, then have both your web app and topshelf app reference that class library. That way you're not in the strange scenario of having a TopShelf/console app referencing a web app. – mason May 26 '22 at 17:08
  • We've been presuming here that you need Hangfire. Take a moment to question that - why do you need it? Just to implement background job processing? Are you using any other features of Hangfire, such as the dashboard? If not, perhaps Hangfire is overkill. Using a messaging passing service to communicate between your site and Topshelf service might be more suitable, such as RabbitMQ, Azure Service Bus, or AWS SQS. – mason May 26 '22 at 17:30

0 Answers0