Well the other difference is the users who can still use IIS Express have .Net 8 SDK installed and those that can’t have .Net 9 SDK installed.
There was a post that multitargeted packages may use the latest version based on the SDK in other words is the project attempting to use V15 on a V13 site?
I’m only targeting .NET 8
I think the only difference is actually IIS vs Kestrel, but I really have no idea what that difference could be.
Don’t currently have the bandwith to investigate, but what other people have done is just taking the little code that the package has and put it straight into their own project, instead of installing the package. Might help.
Oh I just noticed you’re using Umbraco v13. I have not touched that code for 10 months, way before .NET 9 was released. I only ever ran it myself on .NET 8, on IIS(Express), which has never been a problem.
So yes, I can imagine that subtle differences and breaking changes in .NET 9 might be causing this. Please note that for v13, Umbraco only supports .NET 8 and not .NET 9 for this very reason: it’s untested and there might be subtle differences causing problems.
That said, it’s very easy to install .NET 8 and update your .csproj to us that in Kestrel.
Thanks @sebastiaan I appreciate you responding.
The last response I had from the cloud team is they are unable to get the site running to try and fix a different issue and cited the hangfire timeout as the cause.
I will go back to the team and get their thoughts.
You will not be able to run Cultiv.Hangfire version 4 on Umbraco 13, it will simply not show up at all. So I am assuming you have installed the latest v3 of Cultiv.Hangfire.
Ah this reminds me of something else!
Only thing I can say is I’ve had a hard time when I was running hundreds of tasks at around the same time and they all started erroring due to a problem with a remote service, the retry queue then got flooded and my database tables for Hangfire filled up rapidly, slowing the site down to a crawl.
I used the following SQL to do a cleanup:
TRUNCATE TABLE [HangFire].[AggregatedCounter]
TRUNCATE TABLE [HangFire].[Counter]
TRUNCATE TABLE [HangFire].[JobParameter]
TRUNCATE TABLE [HangFire].[JobQueue]
TRUNCATE TABLE [HangFire].[List]
TRUNCATE TABLE [HangFire].[State]
--DELETE FROM [HangFire].[Job]
DBCC CHECKIDENT ('[HangFire].[Job]', reseed, 0)
UPDATE [HangFire].[Hash] SET Value = 1 WHERE Field = 'LastJobId'
Not that --DELETE FROM [HangFire].[Job] is commented out as it could be millions of rows, which will take forever to delete. I think I had a problem truncating instead though, not sure.
Make backups before you attempt any of these queries, and do COUNT queries beforehand to see if you actually have a problem with loads and loads of data.
The other snippet I have laying around is:
SELECT *
-- DELETE FROM
FROM [HangFire].[Set] WHERE [key] = 'recurring-jobs'
-- 'recurring-jobs' is the list of available jobs that will run
-- don't delete them otherwise no jobs will ever run until
-- you reboot the application
As per an issue I had with the Composer (Setting up jobs in Composer throws an error · Issue #21 · nul800sebastiaan/Cultiv.Hangfire · GitHub)
We have this in the v13 project setup:
public void ConfigureServices(IServiceCollection services)
{
//Needed for Hangfire
var sqlStorage = new SqlServerStorage(_config.GetConnectionString("umbracoDbDSN"));
JobStorage.Current = sqlStorage;
services.AddUmbraco(_env, _config)
.AddBackOffice()
...
So, perhaps if someone is running locally and NOT using SQL Server, it would cause an issue?
