Testing .NET Remoting Objects

Reference remote object assembly. To test .NET Remoting objects you must reference the .NET assembly that defines the objects that are remoted. To do this, add a reference to the DLL that defines the classes.

Configure your test driver to be a remoting client. You must tell .NET which classes are remoted. The easiest way to do this is to make the configuration in a .config file. For detailed information about .config files that define a remoting client configuration, see MSDN.

Here is an example file:

<configuration>
 <system.runtime.remoting>
 <application>
 <channels>
 <channel ref="http" port="2000" />
 </channels>
 <client url="http://remoteserver:2000">
 <activated type="RemoteDll.RemoteClass1, RemoteDll" />
 <activated type="RemoteDll.RemoteClass2, RemoteDll" />
 </client>
 </application>
 </system.runtime.remoting>
 </configuration>

This configuration file must be loaded at runtime (ideally in the Init transaction of your test driver). To make sure that this file is available on all agents when running load tests, add it to the project-dependent files (Menu: Silk Performer/Add Dependencies). You can get the correct path using the Bdl.GetDataFilePath method.

Here is example code that configures remoting and instantiates a remote object:

using System;
using Silk Performer;
using System.Runtime.Remoting;
using RemoteDll;
namespace SPProject1
{
[VirtualUser("VUser")]
public class VUser
{
public VUser()
{
}

[Transaction(ETransactionType.TRANSTYPE_INIT)]
public void TInit()
{
 RemotingConfiguration.Configure(Bdl.GetDataFilePath("vuser.config"));
 }

[Transaction(ETransactionType.TRANSTYPE_MAIN)]
public void TMain()
{ // .NET Runtime knows that objects of type RemoteDll.RemoteClass1 are remoted
 RemoteClass1 rm1 = new RemoteClass1();
 rm1.SomeMethod("param");
}

[Transaction(ETransactionType.TRANSTYPE_END)]
public void TEnd()
{
}
}
}

As HTTP was configured as the transporting protocol, you can view the traffic generated for the .NET remoting calls via TrueLog Explorer.