Guidelines for setting .NET filters
When testing your .NET application, your goal is to determine how the server reacts to requests from the client. When load testing, you want to see how the server responds to a load of multiple users.
When recording a .NET application, your script may include calls to methods that do not affect the server, such as calls to a local utility or the GUI interface. These calls are usually not relevant to your testing goals, and it would be correct to filter them out.
The built-in filters, .NET Remoting, ADO.NET, Enterprise Services, and WCF, were designed to record only the server related traffic relevant to your testing goals. In some instances, however, you may need to customize filters to capture your .NET application's calls or exclude unnecessary calls. Using the .NET Recording Filter pane [.NET protocol], you can design custom filters to exclude the irrelevant calls and capture the server related calls.
Before creating a test, we recommend that you become familiar with your application and determine its primary classes and methods, so that you know which ones to include in your recording.
If you are not familiar with your application's classes, you can use Visual Studio or a Stack Trace to help you determine which methods are being called by your application in order to include them in the filter. VuGen allows you to record with a stack trace that logs all of the methods that were called by your application.
Once you determine the required methods and classes, you include them using the .NET Recording Filter pane. When preparing a script, you may need to customize the filter several times in order to achieve the optimal filter. An optimal filter records the relevant methods without introducing a large number of irrelevant calls to the script.
Tip: Strive to modify the filter so that your script compiles (Shift+F5) inside VuGen. Then customize the filter further to create a functional script that runs inside VuGen.
If you plan to add manual code to your script such as control flow or message statements, make sure to do so after you have a functional script that runs inside VuGen. The reason for this is that if you re-record a script or regenerate the script, you will lose all of the manual changes.

When designing a custom filter, we recommend that you start by choosing the appropriate built-in filter as a base filter. You can then customize the filter using one of the following approaches:
-
Top Down Approach. An approach in which you include the relevant namespace and exclude specific classes that are not part of the client-server activity. This is recommended if you are familiar with your application and you can identify a well-defined assembly which implements all client-server activity without involving any GUI elements, such as MyDataAccessLayer.dll.
-
Bottom up Approach. An approach in which you use the default filter and refine it by adding individual methods or classes. Use this approach if you cannot identify a well-defined layer or if you are not familiar with your application. Do not add all AUT assemblies and then try to remove extra component one by one.
The following guidelines indicate when to include or exclude elements:
-
If, as a result of your including a class, your script has many unrelated method calls, try modifying the filter to exclude the irrelevant methods.
-
If you identify a non-client/server call in your script, exclude its method in the filter.
-
During recording, VuGen may detect an unknown input argument, for example, an argument whose construction it had never encountered before. If this argument supports serialization, VuGen serializes it by saving it to a file in a special format. During replay, VuGen reconstructs the argument by deserializing it.
-
VuGen serializes objects passed as arguments that were not included by the filter. We recommend that you include this object in the filter in order to track its construction and activity instead of using it in its serialized form. You can identify serialized objects in the script by searching for calls to the LrReplayUtils.GetSerializedObject method or, in WCF environments, LrReplayUtils.GetSerializedDataContract. VuGen stores serialized objects in the script's \data\SerializedObjects folder as XML files with indexes, Serialization_1.xml, Serialization_2.xml and so forth.
-
When no rules are specified for a method, it is excluded by default. However, when the remoting environment is enabled, all remote calls are included by default, even if they are not explicitly included. To change the default behavior, you can add a custom rule to exclude specific calls which are targeted to the remote server.
-
Arguments passed in remoting calls whose types are not included by the filter, are handled by the serialization mechanism. To prevent the arguments from being serialized, you can explicitly include such types in order to record the construction and the activity of the arguments.
-
Exclude all activity which involves GUI elements.
-
Add assemblies for utilities that may be required for the script to be compiled.
For information on how to include and exclude elements, see .NET Recording Filter pane [.NET protocol].
Tip: You can include or exclude a method directly from the VuGen editor. Select the method and choose Open current method in Filter Pad from the right-click menu. Once the method is selected in the filter tree, choose Include or Exclude from the right-click menu.


When preparing a script, you may need to customize the filter several times in order to achieve the optimal filter. An optimal filter records the relevant methods without introducing a large number of irrelevant calls to the script.
To define an effective filter:
-
Create a new filter based on one of the built-in filters. If you know that the AUT (Application Under Test) does not use ADO.NET, Remoting, WCF, or Enterprise Services, clear that option since unnecessary filters may slow down the recording.
-
Set the Stack Trace option to true for both recording and code generation. Open the Recording Options ( ctrl+f7) and select the Recording node. Enable Debug Options: Stack Trace and Code Generation: Show Stack Trace.
-
Record your application. Click Start Record ( ctrl + r) to begin and Stop ( ctrl + f5) to end.
-
View the script's steps. If you can determine the business logic from the steps and apply correlation, you may not need to create custom filters. If, however, the script is very long or hard to maintain or correlate, you should customize the script's filter.
-
Try to identify the high-level method in the call that captures or wraps one or more client server calls. You can do this by opening the AUT source files (if they are available) in Visual Studio or by viewing a Stack Trace of the script.
-
Set the filter to include the relevant methods—you may need to add their assembly beforehand. For tips about including and excluding elements in the filter, see .NET filters overview.
-
Record the application again. You should always re-record the application after modifying the filter.
-
Repeat steps 4 through 7 until you get a simple script which can be maintained and correlated.
-
After creating an optimal script, turn off the Stack Trace options and regenerate the script. Open the Recording Options ( ctrl+f7) and select the Recording node. Disable Debug Options: Stack Trace and Code Generation: Show Stack Trace. This improves the performance of subsequent recordings.
-
Correlate the script. For your test to run properly, you may need to insert a correlation to capture a value and use it at a later point in the script. For more information, see Microsoft .NET correlation.