BatchQueue question - using application defined objects as request-state

BatchQueue question - using application defined objects as request-state

Old forum URL: forums.lhotka.net/forums/t/1090.aspx


lewischris posted on Thursday, August 31, 2006

Hi,

I've come up against another issue with the CSLA 1.x BatchQueue component that I would appreciate some help with.

I am submitting BatchRequestJobs along with an application-defined 'state' object (say 'MyRequestState') - which contains all the information (parameters) needed about how to process the job.

However, when submitting this BatchRequestJob + state to the queue, the

CSLA.BatchQueue.Server.BatchQueue (server-side) object needs a reference to the assembly in which the 'MyRequestState' object is defined - so it knows how to serialize it!

How can I get around the need to reference my assembly from the CSLA BatchQueue? Sorry if I'm missing something here!

Chris

 

RockfordLhotka replied on Thursday, August 31, 2006

CSLA doesn't need a reference to that assembly, but the assembly does need to be in the assembly load path for .NET when the code is running.

This is no different from the data portal. CSLA doesn't have a reference to your business assemblies, but it is able to dynamically load them as needed because your assemblies are in the bin directory (the assembly load path) on the server.

The same thing is true here. You should be able to put your business assemblies into the same directory as the EXE that is hosting the service on the server, because that would be the assembly load path for that application.

lewischris replied on Thursday, August 31, 2006

Thanks for the help.

I think this has come about because I have hosted the "accept and queue BatchJobRequest" in IIS and I haven't got the references for the web project set correctly - I've done that now, but am getting type resolution problems - probably because the client and server are now referencing different versions of the same assembly - I need to get the project build order sorted out!

Chris

 

Copyright (c) Marimer LLC