I have a .NET application in which assemblies in separate AppDomains must share serialized objects that are passed by value.
Both assemblies reference a shared assembly that defines the base class for the server class and also defines the base class for the entiy type that will be passed between domains:
public abstract class ServerBase : MarshalByRefObject
{
public abstract EntityBase GetEntity();
}
[Serializable]
public abstract class EntityBase
{
}
The server assembly defines the server class and a concrete implemetation of the entity type:
public class Server : ServerBase
{
public override EntityBase GetEntity()
{
return new EntityItem();
}
}
[Serializable]
public class EntityItem : EntityBase
{
}
The client assembly creates the AppDomain
in which the server assembly will be hosted and uses an instance of the server class to request a concrete instance of the entity type:
class Program
{
static void Main()
{
var domain = AppDomain.CreateDomain("Server");
var server = (ServerBase)Activator.CreateInstanceFrom(
domain,
@"..\..\..\Server\bin\Debug\Server.dll",
"Server.Server").Unwrap();
var entity = server.GetEntity();
}
}
Unfortnately, this approach fails with a SerializationException
because the client assembly has no direct knowledge of the concrete type that is being returned.
I have read that .NET remoting supports unknown types when using binary serialization, but I am not sure whether this applies to my setup or how to configure it.
Alternatively, is there any other way of passing an unknown concrete type from the server to the client, given that the client only needs to access it via its known base class interface.
Thanks for your advice,
Tim
EDIT:
As requested by Hans, here is the exception message and stack trace.
SerializationException
Type is not resolved for member 'Server.EntityItem,Server, Version=1.0.0.0,Culture=neutral, PublicKeyToken=null'.
at Interop.ServerBase.GetEntity()
at Client.Program.Main() in C:\Users\Tim\Visual Studio .Net\Solutions\MEF Testbed\Client\Program.cs:line 12
at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
I think I have a solution thanks to current post, and this one and its accepted answer : AppDomain.Load() fails with FileNotFoundException
First thing, I think you should use an interface in place of a base class to be your handler. The interface should be declared on base class, and then you only use it.
Solution : create a concrete type in the shared assembly, which inherits from
MarshalByRefObject
, and implements your server interface. This concrete type is a proxy that can be serialized/deserialized between AppDomains because your main application knows its definition. You no longer need to inherit fromMarshalByRefObject
in your classServerBase
.Note: in order to send and receive data, each type declared in IServer must be serializable (for example: with
[Serializable]
attribute)Then, you can use the method found in previous link "Loader class". Here is my modified Loader class which instanciate concrete type in shared assembly, and returns a Proxy for each Plugin:
Then, in the master application, I also use the code of "dedpichto" and "James Thurley" to create AppDomain, instanciate and invoke Loader class. I am then able to use my Proxy as it was my plugin, because .NET creates a "transparent proxy" due to
MarshalByRefObject
:It's really hard to find out a working solution, but we finally can keep instances of custom proxies of our concrete types instanciated in another AppDomain and use them as if they was available in main application.
Hope this (huge answer) helps !
This fails because the CLR just has no hope of being able to find the assembly, you put it in an unfindable location. Trivially solve this by adding a reference to the assembly and setting its Copy Local property to True so that server.dll gets copied into your build directory. If you want to keep it where it is at then you'll have to implement AppDomain.AssemblyResolve to help the CLR finding it.
I asked a related question a while back:
Would you say .Net remoting relies on tight coupling?