glad to hear your problem is fixed

for future reference: you’re better off asking your questions on the official agatha google groups list: http://groups.google.com/group/agatha-rrsl/

That way other people might answer when i’m not available, and every answer can be indexed by google or referred to later on

public static void Register()
{
var agathaConfig = new ServiceLayerConfiguration(typeof(Agatha.Unity.Container));
agathaConfig.AddRequestHandlerAssembly(Assembly.GetExecutingAssembly());
agathaConfig.AddRequestAndResponseAssembly(typeof(GetClaimRequest).Assembly);
agathaConfig.AddRequestAndResponseAssembly(typeof(DischargeCertificateReceivedCommand).Assembly);
agathaConfig.Initialize();

Thanks for your excellent request/response service layer.

We are having a problem when using the net.tcp binding and hosting with WAS. How do you normally go about registering the Request and Response assemblies. When hosting in an ASP.NET application using an http binding under IIS, we would normally call AddRequestAndResponseAssembly methods via the Global.asax. Unfortunately this doesn’t get called when running under WAS.

I’ve attempted to create a custom ServiceHostFactory and subscribe to the Host.Opening event to do the registration. It seems to work and calls my ComponentRegistration.Register() method, however when Agatha tries to deserialize a request from my client, it complains about unknown types. It’s like the ComponentRegistration hasn’t worked.

For the benefit of future searchers that land here with a similar scenario, I am also considering getting the server to generate the initial state of the database and then it becomes just a regular file download. This then means the settings in wcf that I’ve just maxed out become more relevant again rather than being set to highest for the sake of one initial transaction.

well, if you’re doing it to implement some synching-features, then there’s nothing wrong with it

my comments was targeted to devs who sometimes send a _lot_ more data over the wire than they should for regular service calls

Our scenario is that we are using WCF to keep multiple clients in sync with a server-side datastore. Now when a new client is added we need to sync all of the data and from then on just offer incremental updates. This initial sync has led to our finding the above mentioned configuration within WCF (which I believe should be the default with recommendation to reduce – but that’s another discussion). Your last sentance: “Being able to send your entire database over the wire doesn’t mean it’s a good idea to actually do so ” intrigued me to asking what you would suggest instead as this is essentially what we’re doing for new systems?

if you’re hosting through IIS, make sure you enable large uploads in your web.config:
http://weblogs.asp.net/jgalloway/archive/2008/01/08/large-file-uploads-in-asp-net.aspx