Closed terryaney closed 5 months ago
A lot of logic was added to ensure smooth co-existence of .NET Framework and .NET Core servers at the same time, to be able to create and consume jobs from each other. However, I don't remember anything regarding Linq, since these types aren't something usually used as background job parameters.
How does your background job method look like, can you send its full signature, including parameter types you are using to reproduce the behavior?
This Hangfire implementation/framework of ours was written 10 years ago maybe, lol. Looking at my JobInvoker
method and trying to figure out why some of the things done are being done, but here is the signature:
public void Invoke( string jobName, XElement inputPackage, PerformContext performContext, IJobCancellationToken cancellationToken )
I'm not in a position to be able to modify that. I could maybe add a string inputPackage
overload if that would help?
I'm not in a position to be able to modify that. I could maybe add a string inputPackage overload if that would help?
Perhaps this would be the best solution as for now, since contents of an XElement is string, but I will check the binding anyway.
FYI...probably totally going against what I am supposed to do but hopefully temporary. Having weird issue with integration testing with my mix of Core and Framework. With all the problems I'm having, until I can I migrate to .NET Core completely I think I'm going to just directly inject the row into the Hangfire Sql DB then let the HF server of mine pick up the job. How crazy am I? lol
Here's what I ended up doing as a work around until I properly move everything to latest/greatest .NET Core/HangFire
var qb = cn.QueryBuilder( $@"
set xact_abort on;
set nocount on;
declare @jobId bigint;
declare @stateId bigint;
begin tran;
insert into HangFire.Job (InvocationData, Arguments, CreatedAt, ExpireAt)
values ({invocationData:nvarchar(max)}, {arguments:nvarchar(max)}, {now}, DATEADD(day, 1, {now}));
select @jobId = scope_identity();
insert into HangFire.JobParameter (JobId, Name, Value)
values (@jobId, 'CurrentCulture', '""en-US""'), (@jobId, 'CurrentUICulture', '""en-US""');
insert into HangFire.State (JobId, Name, CreatedAt, Data)
values (@jobId, 'Enqueued', {now}, {state:nvarchar(max)})
select @stateId = scope_identity();
UPDATE HangFire.Job
SET StateId = @stateId, StateName = 'Enqueued'
WHERE Id = @jobId
INSERT INTO HangFire.JobQueue (JobId, Queue) VALUES (@jobId, 'default' )
commit tran;
SELECT @jobId
" );
var hangfireId = await qb.QueryFirstAsync<int>( cancellationToken: c );
Peeked at commit. Looks like you would support my scenario natively now?
Yep, it works now, the problem happened when old .net framework tried to deserialize a type from the new one.
New one had necessary bindings to handle from the old one, but not the vice versa. I just added one more redirect, so should work now.
Hope will solve weird problems with the new release next week.
I have an abnormal (temporary) environment. My original implementation was a Windows Service hosting Hangfire as the job processing host, written in .NET Framework.
Then, I had .NET Framework sites/apis that used something like:
To perform a fire/forget job.
We are slowly migrating everything to .NET Core, but need to be in 'mixed' environment until migration is complete. I was hoping to upgrade only an API to .NET Core and have it leverage the existing .NET Framework Windows Service.
In my .NET Core Api project, I referenced my .NET Framework assembly containing
JobInvoker
and use the same line as above. My intention was for it to simply schedule the job into the Hangfire SQL db and my .NET Framework Windows Service would pick it up and process it. But after Enqueue call, the job fails with this exception:It seems like it is trying to resolve .NET Core LINQ to Xml objects? I could be wrong, but the namespace of 'System.Private.Xml.Linq' was not something I was used to seeing in .NET Framework.
Is there a way to do what I'm trying to do? Or a workaround I can perform for this non-standard setup I'm stuck in for a while?