Fog Creek Software
Discussion Board




Welcome! and rules

Joel on Software

AppDomains and Collections-ie.serialization probs

I'm working with writing a program that loads plugins from libraries. The plugins are created in their own AppDomain as a workaround so they may later be unloaded.

What the plugin does is gets created as a singleton upon program start and then each time it is needed, a Process() method is called. The Process method takes an object and returns nothing (void). The object it takes though, as a side effect, is modified for use by the main part of the application later.

This works great for everything EXCEPT Collections (*any* type of collections: a custom Collection class, Hashtables, ArrayLists, etc). Collections just seem to drop whatever changes I try to make due to being in different AppDomains. I've tried marking everything as both Serializable as well as MarshalByRefObject, to no avail.

So what I'm wondering is -- is there any way whatsoever to get this working!? I could post some code if necessary. Any help would be soooo appreciated!

Thanks,
Ian

Ian Sefferman
Wednesday, July 28, 2004

Random thought: how about you serialize the collection using BinaryFormatter and passing the byte[] in - and deserialising it in the other appdomain?

Duncan Smart
Wednesday, July 28, 2004

Instead of ...

void modify_object(object foo)
{
  //modifies foo
  Class.singleton.Process(foo);
}

... would it work to do ...

object modify_object(object foo)
{
  //returns a modified foo
  return Class.singleton.Process(foo);
}

Christopher Wells
Wednesday, July 28, 2004

Well, I'm not exactly sure how that would work -- I guess I didn't really explain myself too well. The Process() method passes an object that contains the collection object as a member var. So would you deserialze the complete object being passed? Or just offer a "deserialized version" of the collection object within the object being passed?

The solution we came up with this morning, which is likely the best solution, was to create our own collection object and not have anything to do with System.Collections (ie. don't inherit from CollectionBase) and MarshalByRefObject that. This is now working really well -- but I'm not sure what type of performance hit it suffers from. Hopefully it's about equal to that of serializing/deserializing things.

The other option we were exploring was using .Net Remoting and sending things through TCP sockets -- but I imagine the overhead on that is just absurd.

Here's to hoping this app doesn't get bogged down from here!

Thanks for all your help! :)
Ian

Ian Sefferman
Wednesday, July 28, 2004

Damn, that last reply was to Duncan.

Christopher:
We tried making the Process() method return the object we wanted, but this also doesn't work. It only seems too simple, right? ;)

Thanks again,
Ian

Ian Sefferman
Wednesday, July 28, 2004

Hi,
when you pass an objects across appdomain boundaries, you are using remoting. There are 2 ways  of passing object by ref and by val.
Inheriting from MBR makes the object passed by ref, while making it [Serializable] passes it by val. If you do both, MBR takes precedence.
As CollectionBase does not inherit from MBR, it is passed by val. If you invoke a method which accepts a collection object for a parameter, this parameter have to be passed with ref or out in the parameter list in order to update your original object.
If that collection is part of an object, which is MBR, then I'd suggest not to expose it as a public member, and to not allow the processing method to touch it directly. Keep it private, and provide some wrapper property/methods in your main object, which deals with the collection internaly. This way, all the processing will happen in the original appdomain, and the collection itself will not be passed.

Hope that helps
Sunny

Sunny
Thursday, July 29, 2004

P.S.
you have to take care what objects you have in your collection as well.  If some of them are [Serializable] they will be passed by val, and MBRs will be passed by ref.
Sunny

Sunny
Thursday, July 29, 2004

*  Recent Topics

*  Fog Creek Home