Problems registering a dynamic type in a .Net Remoting Service

I am using Emit to create some dynamic types in my project, particularly to replace "Decorators" around my service interfaces. I am also doing this for the class registered with .Net Remoting as the WellKnownServiceType. However, .Net Remoting does not seem to be working very well with dynamically emitted types. First, I got:

System.IO.FileNotFoundException: Could not load file or assembly 'Dynamic, Version=0.0.0.0, Culture=neutral, PublicKeyToken=XXXX' or one of its dependencies. The system cannot find the file specified.

Of course the file doesn't exist, the assembly is dynamic, and I have set Emit to only "Run" the assembly, not SaveAndRun.

So, before registering the type, I call an Assembly.Load(type.Assembly.GetName()). Now, I get:

System.Runtime.Remoting.RemotingException: Requested Service not found
Server stack trace: 
   at System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders requestHeaders, Stream requestStream, IMessage& responseMsg, ITransportHeaders& responseHeaders, Stream& responseStream)

The error appears only on the client side as an e开发者_Python百科xception from the server. I don't see any errors in the server logs.

Anybody has clues on whether this is a "wellknown" issue, that dynamic types can not be used to host .net remoting services ? Any hints or pointers to work around it ?

** UPDATE **** I've stopped using Emit. Emit forced me to put an "InternalsVisibleTo" attribute in my core assemblies, which seriously affected obfuscation. Rather, I've switched to code generation using CodeDom namespace. It works beautifully. I can see the actual source code that does the job, which is very helpful when debugging.

I recently hit this exact same problem. As you've probably noticed from the stack trace, the problem comes from Assembly.Load

Server stack trace: 
   ...
   at System.Reflection.Assembly.Load(...)
   at System.Runtime.Remoting.RemotingConfigHandler.RemotingConfigInfo.LoadType(String typeName, String assemblyName)
   at System.Runtime.Remoting.RemotingConfigHandler.RemotingConfigInfo.GetServerTypeForUri(String URI)
   at System.Runtime.Remoting.RemotingConfigHandler.GetServerTypeForUri(String URI)
   at System.Runtime.Remoting.RemotingServices.GetServerTypeForUri(String URI)
   at System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(...)

You can provide an AssemblyResolve event handler to allow you to control the loading of your custom assemebly. vis:

AppDomain.CurrentDomain.AssemblyResolve += delegate(object sender, ResolveEventArgs args)
{
    if (args.Name.Equals(type.Assembly.FullName))
        return type.Assembly;
    return null;
};