'System.ObjectDisposedException' in System.Transactions.dll

[ddiosdado-tea]

I am currently trying out Hangfire, checking if it can be used in conjunction with some old .net 4.7 code we currently have, I created a new console application targeting net 4.7, added the Hangfire.Core and Hangfire.SqlServer packages both are versions 1.8.15. The console app is very simple:

static void Main(string[] args)
{
    GlobalConfiguration.Configuration.UseSqlServerStorage("ConnectionString");
    using (var server = new BackgroundJobServer())
    {
        Console.WriteLine("Hangfire Server started. Press any key to exit...");
        Console.ReadKey();
    }
}

I am firing a job from our api(separate project also written in 4.7), the job gets executed but I can see the following exceptions before and after the job is executed:

Exception thrown: 'System.ObjectDisposedException' in System.Transactions.dll

I forced VS to throw the exception in order to get more details:

Cannot access a disposed object.
Object name: 'Transaction'.
at System.Transactions.Transaction.get_TransactionInformation()

Tracked it down here:
AppData\Local\SourceServer\..\src\Hangfire.SqlServer\SqlServerDistributedLock.cs
using (var command = CreateReleaseCommand(connection, resource, out var resultParameter))
{
    command.ExecuteNonQuery();

I am aware of a similar issue but the solution there was just to sort of ignore the exception, is that really ok?

By the way I also tried running the same console app but this time targeting .net 5 and no exceptions are thrown there.

[odinserj]

This is how the EnlistedTransactionDisposed property getter is implemented, please see https://github.com/HangfireIO/Hangfire/issues/1348#issuecomment-466405550 for details. Hangfire.SqlServer for newer platforms doesn't use System.Transactions assembly, that's why you don't have those exceptions.

[odinserj]

Also, the release command is being executed anyway, this is just a first-chance exception handler that doesn't cause the command to be aborted.

[ddiosdado-tea]

I see, and you are right, my commands are still being executed, it just makes my team nervous to see those underlying exceptions, thanks for the amazing library and also thanks for the prompt response, I appreciate it.