Hi,

We have a .NET remoting application server, which works great by itself.
We are currently evaluating a commerical automated testing tool, that loads the application server's API assembly and simulates a client connection to the server. However, under this scenario the proxy object does not succeed in dealing with complex objects, and we get the "Return argument has an invalid type" error in return.

We figured it has something to do with security issues but couldn't find any solution. We are using a tcp binary channel with typeFilterLevel=Full. The interface for the complex object AND the complex object itself are defined in a separate assembly (ApplicationServer) then the API (ApplicationSeverAPI).

Thanks,

Ron

It comes from within the .NET framework:

System.InvalidCastException: Return argument has an invalid type.
at System.Runtime.Remoting.Proxies.RealProxy.ValidateReturnArg(Object arg, Type paramType)
at System.Runtime.Remoting.Proxies.RealProxy.PropagateOutParameters(IMessage msg, Object[] outArgs, Object returnValue)
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Remotable.RemoteClass.get_MiscObj()
at ClientAPI.RemotingAPI.Connect in d:\dev\remotingnet\clientapi\remotingapi.cs:line 71

Could you paste an abstract version of your ClientAPI.RemotingAPI.Connect class and any subsiquent return types

Also, are these return types common to both server and client

The return types are common to both server and client.

Now let me try and give you an abstract of what is going on there:

In my RemotingObject Assembly I have both the RemoteObject and Misc, both derive from MarshalByRefObj. RemoteObject has Misc as a property. Misc is instanciated when RemoteObject is created. it looks something like this:

namespace Remotable
{
[Serializable]
[ComVisible(true)]
public class RemoteClass : MarshalByRefObject
{
private Misc misc = null;
private string dummy = "Dummy text";

public IMisc MiscObj { get { return misc; } }
public string Dummy { get { return dummy; } }

public RemoteClass()
{
misc = new Misc();
}
}

[Serializable]
public class Misc : MarshalByRefObject, IMisc
{
public Misc() { }

public string GetServerString()
{
return "Hello! Time: " + DateTime.Now.ToString("dd/MM/yyyy HH:mm:ss");
}
}

}

2 things; First you should only need to make the class serializable or MBR (MarshallByRefObject). In this particular instance I'd stick with MBR; so you can remove the [Serializable] attribute from both classes. Also, why do you need ComVisible

Second, have you declared both RemoteClass AND Misc (and possibly IMisc aswell) as well known types on your server

Thanks for your help r3n!

Actually I declared only RemoteClass as a well known type, but even after declaring Misc & IMisc as well known types on the server (and the client, just to be on the safe side) - the error keeps occuring.

Also, I've removed the [Serializable] attribute from both classes. The [ComVisible] attribute is there as we're exposing the API with a COM interface as well. For this small example I agree - it is not needed.

Anyway - problem still there. Any other thoughts

To be truthful, you don't really need to declare Misc and IMisc as well known types unless you're instantiating them directly using GetObject -- which would explain why it doesn't solve the issue -- but I thought it wouldn't hurt to try.

As for declaring them client side, this is not necessary.

Perhaps you could publish the solution in a ZIP so I can take a closer look

The problem is purely in the automatic testing tool and not in the solution itself.

Anyway I managed to figure out a not-the-best-but-will-do way around it: I've created a windows-form application and wrapped all the methods of my API to be the form's methods. The testing tool seems to be able to run the form's methods without any problem. The security issue for the remoting was solved since the windows-form application is the one creating the proxy and not the testing tool.

Anyway, again, thanks for your help.

The problem is purely in the automatic testing tool and not in the solution itself.

I would have thought this to be sort of obvious

I had the same problem, for me the solution was to put the assembly with the type which should be returned by the remoting function into the GAC

So no security, but more a file not found issue...