Support matrix

.NET frameworks

  • 2.0
  • 3.0
  • 3.5
  • 4.0
  • 4.5

.NET app frameworks

  • WCF IIS

.NET IIS versions

  • 7.0
  • 7.5
  • 8.0
  • 8.5

.NET databases

  • Microsoft SQL Server
  • Oracle

.NET http clients

  • httpwebrequest
  • HttpClient

Installing instrumentation

There is a .NET agent installer which installs the required dlls and configuration files under ProgramFiles\AppNeta\TraceView\dotnet. When you run the installer, your web application will become unavailable for the time it takes for the affected application pools to restart.

  • Run the .NET agent installer, or to install the agent via the command line.

    # to install the .net agent via the command line
    # square brackets indicate an optional parameters
    # the pipe character separates multiple choices within an option
    # for /COMPONENTS specify "IISOnly,NonIISApplications" to instrument non-IIS applications as well.
    DotNetAgent_Setup.exe [/SILENT | /VERYSILENT] /COMPONENTS="IISOnly[,NonIISApplications]" [/CLOSEAPPLICATIONS | /NOCLOSEAPPLICATIONS]
    
  • If you decided to instrument non-IIS applications add the following snippet to the agent config file, which is in ProgramFiles\AppNeta\TraceView\dotnet.

    <applications>
    # add one line for each non-IIS application that should be instrumented
    <application name="_application-name.exe_" />
    </applications>
    
  • When you are ready to start tracing, restart the application pools in which your apps are running via the iisreset command-line tool.
  • Now any traffic made through IIS will be traced, and you’ll see it in TraceView.

Troubleshooting installation

TraceView installers and agents log detailed information about problems they run into, which can provide helpful information during troubleshooting.

  • Records of the host agent install process are in C:\Program Files\AppNeta\TraceView\Setup Log timestamp.txt.
  • Process logs are located in C:\windows\temp\tracelyzer_timestamp.log.
  • Tracelyzer logs are are in C:\windows\temp\tracelyzer_timestamp.log.
  • Records of the instrumentation install process are in C:\Program Files\AppNeta\TraceView\dotnet\instrumentation_setup.log.

Uninstalling instrumentation

Uninstall .NET instrumentation via the command line. This command does not uninstall the Tracelyzer and its dependencies. For that see uninstalling that see this article.

# square brackets indicate an optional parameters
# the pipe character separates multiple choices within an option
C:\Program Files\AppNeta\TraceView\dotnet\unins000.exe [/SILENT | /VERYSILENT] [/CLOSEAPPLICATIONS | /NOCLOSEAPPLICATIONS]

Upgrading instrumentation

To upgrade .NET instrumentation, simply re-install it.

Configuring instrumentation

Change the logging configuration

The default logging level is ‘Info’. This the minimum severity required to report Info, Warning, Error and Fatal messages to the logs. By default one log file per app is created in \TEMP\AppNeta (where TEMP is the system environment variable: TEMP) with a timestamp as part of its naming convention. The file ages out periodically at which point a new file is created. Segmenting the log history this way makes logs a little easier to search and handle. To protect hosts against disk space issues, logs may be written only if there is sufficient disk space; older files are purged; and they are subject to a maximum size. Once the max file size is reached, no logs are written until a new file is created. This occurs either when the current file ages out, or if the current file is renamed, a new file will be created immediately.

Disable inlining optimization

If a method is trivial enough, CLR might decide to inline the method, which is optimization that replaces a method call with the method body. If that happens, the method doesn’t exist anymore and so TraceView can’t instrument it. To prevent this, inlining can be disabled either for an individual method, as shown, or for all apps via the inlining config parameter.

[MethodImpl(MethodImplOptions.NoInlining)]
void YourMethod()
{ // do something }

Disable tracing for static files

You can disable tracing for static files using the url sample rate config. Basically you add an instrumentation block to the bottom of agent.config. That block should contain a regular expression describing the file extensions you want to exclude, plus a trace mode setting. An example is included in agent.config itself. You must run iisreset in order for any changes to take effect.

...
</appSettings>  
  <instrumentation>  
    <urlSampleRates>
      <!-- Setting a URL Specific Tracing Mode or Sample Rate -->
      <!--   Element: urlSampleRate -->
      <!--   Attributes: -->
      <!--     urlMatch (regular expression to match against the url with the protocol removed) -->
      <!--     tracingMode (Always, Never, Through) -->
      <!--       -If the tracingMode is Never or Through the sampleRate should not be set.-->
      <!--       -If the tracingMode is Always the sampleRate is required. -->
      <!--     sampleRate (Valid values are any integer between 0 and 1000000 (100%))-->
      <!--   Example: -->
      <!--     <urlSampleRate urlMatch=".*\.(png|jpg|jpeg|gif)" tracingMode="Never" /> -->
    </urlSampleRates>    
    <applications>
      <!-- The list of non-IIS Applications to instrument-->
      <!--   Element: application -->
      <!--   Attributes:  -->
      <!--     name: The name of the application to instrument. -->
      <!--     inlining: Optional attribute. Valid Options: Disabled, Enabled -->
      <!--               If the inlining attribute is not set in the application element, the appSettings Inlining value is used. -->
      <!--  Example:  -->
      <!--    <application name="ApplicationToInstrument.exe" /> -->
    </applications>
  </instrumentation>
</configuration>

Complete config options

You can change the .NET agent behaviour by editing agent.config—renamed from AppNeta.TraceView.dll.config—located in .NET agent directory C:\Program Files\AppNeta\TraceView\dotnet\. You must run iisreset in order for any changes to take effect.

AppNeta.SQLSanitizationMode

config option
AppNeta.SQLSanitizationMode
description
The .NET instrumentation has the ability to sanitize query literals from sql statements. By default this is disabled. Set to one of the other options to avoid collecting and reporting query literals to TraceView.
possible values
Disabled
Disable sanitization of query literals.
Auto
Remove literals, auto-detecting literal quotes.
DropDoubleQuotes
Remove literals and double-quoted values.
KeepDoubleQuotes
Remove literals but keep double-quoted values.
history
Introduced in version 1.1.5
example
<add key="AppNeta.SQLSanitizationMode" value="Disabled" />

TracingMode

config option
TracingMode
description
Change the tracing mode.
possible values
Always
(Default) Continue existing traces, otherwise attempt to start a new one.
Through
Continue existing traces, but never start them. This mode assumes that a higher layer makes the decision about whether to trace.
Never
Never continue existing traces or start new ones.
history
Introduced with the original .NET instrumentation
example
<add key="TracingMode" value="Always" />

urlSampleRate

config option
urlSampleRate
description
Disable tracing for urls matching a user-configurable regular expression. If your agent.config file doesn’t have the instrumentation section shown in the example, paste it in and then make your changes.
parameters
urlMatch
A regular expression. Matching urls will honor the trace mode that follows. There are no defaults, which means that tracing is not disabled for any static files or urls by default.
tracingMode
This value overrides the default, determined by TracingMode. Set to ‘Always’ to enable tracing for matching urls or ‘Never’ to disable tracing for matching urls.
sampleRate
Do not change unless instructed by customer care. This option must be present for tracingMode=Always to take effect.
history
Introduced in version 2.0.0
example
See disable tracing for static files.

Inlining

config option
Inlining
description
If a method is inlined by CLR, it cannot be instrumented. You can disable inlining for all applications through this config option.
Valid Options
Disabled, Enabled. Default: Enabled.
history
Introduced in version 2.0.0
example
<add key="Inlining" value="Disabled" />

SecurityTransparencyInstrumentation

config option
SecurityTransparencyInstrumentation
description
If an assembly has the SecurityTransparent attribute then any methods instrumented in it might cause a System.Security.VerificationException to occur, and a web request that invokes those instrumented methods might fail. By default instrumentation of SecurityTransparent assemblies is disabled but it can be enabled with this config option.
Valid Options
0
(Default) Disable instrumentation for security transparent assemblies. When this value is set instrumentation will be disabled for MVC3 and MVC4.
1
Enable instrumentation for security transparent assemblies. When this value is set MVC3 will be instrumented but MVC4 will not.
2
Set the compiler flag that disables transparency checks. When this value is set, System.Security.VerificationException won’t occur even if both the SecurityTransparent attribute and TraceView instrumentation are present.
history
Introduced in version 2.0.0
example
<add key="SecurityTransparencyInstrumentation" value="1" />

LogCreationSchedule

config option
LogCreationSchedule
description
Specify when the current log file ages out and a a new log file should be generated.
possible values
Daily or Weekly. The default is Daily.
history
Introduced in version 2.0.0
example
<add key="LogCreationSchedule" value="Daily" />

LogFileMaxSize

config option
LogFileMaxSize
description
The maximum size, in bytes, that a log file may be. After the maximum is reached, no additional messages will be written to it. Log messages will be written again once a new log file is generated. The default is 10000000 (10 MB).
history
Introduced in version 2.0.0
example
<add key="LogFileMaxSize" value="10000000" />

LogLevel

config option
LogLevel
description
Change the logging severity level. The default is ‘info’, which is the minimum level required to capture trace events, e.g., entry, exit, etc.
possible values
In order of descending: Fatal, Error, Warning, Info, Debug, Trace, none.
Fatal
An error caused .NET instrumentation to stop.
Error
Any error caused an instrumented trace to fail.
Warning
An issue such as an unexpected configuration value, but the .NET instrumentation can still generate traces.
Info
Logging items such as configuration settings that were loaded on start up.
Debug
Diagnostic information used by customer care to resolve technical issues.
Trace
Highest level of logging. Logs functions called, exception stack traces, etc.
none
No logging.
history
Introduced in version 2.0.0
example
<add key="LogLevel" value="Info" />
Note
Levels Info and higher do not log messages per request when the .NET agent is running as expected.

LogRetentionDays

config option
LogRetentionDays
description
Retain old log files for the specified number of days, after which they will be deleted. The default is 45 days.
history
Introduced in version 2.0.0
example
<add key="LogRetentionDays" value="45" />

ReserveDiskSpace

config option
ReserveDiskSpace
description
The amount of disk space, in bytes, that must be available before messages can be written to a log file. Log messages will not be written if there is insufficient disk space. The default is 200000000 (200 MB).
history
Introduced in version 2.0.0
example
<add key="ReserveDiskSpace" value="200000000" />

Customizing instrumentation

In order to make use of the .NET API, you’ll need to add AppNeta.Instrumentation.dll as a reference in your project. This .dll is automatically installed in Program Files\AppNeta\TraceView\dotnet when you upgrade the .NET agent to version 1.4.0 or newer.

Customize out-of-box instrumentation

Customization involves adding hooks from our public API to your code so that you can to take advantage of additional filtering capabilities on the dashboard, change how requests are traced, or capture additional information during the trace.

.NET partitions

With hundreds of traces flowing into your dashboard, you need a way to keep them organized. For this, TraceView provides ‘partitions’, a programmatic way of classifying traces. For example, you can place traces into the following classes: anonymous, authenticated, and administrator. On the dashboard, partitions appear as a filter on the same level as urls and controller/action pairs, so in this example you could choose to limit the display to just requests of authenticated users. Traces are not assigned to any partition by default, and you are free to partition requests however you need to feel that your app is logically arranged. To assign a trace to a partition, just fire an info event anywhere within the trace and attach the partition key/value pair. Partition names may have a maximum length of 40 characters, anything longer is truncated to 40. They’re also limited to alphanumeric characters, or underscores. Any characters that don’t fit this criteria are silently converted to underscores.

public class YourClass {
    void yourMethod() {
        // A null layer name inherits the current layer.
        TraceEvent event = <a href="#CreateInfoEvent">Trace.CreateInfoEvent(null)</a>;   
        event.AddInfo("Partition", "your_partition_name"); 
        event.Report(); 
    }
}

.NET custom layers

By default, the .NET instrumentation creates a layer for the code itself, e.g., ‘IIS’, ‘WCF-Service’, ‘ado-mssql’. If these layers don’t provide enough visibility, you can further divide your code into sub-layers. How you segment your application modules and sub-systems into layers is entirely up to you. For example the out-of-box instrumentation might not recognize calls to external processes, so you could use the API to manually create layers for them. Similarly, multi-threaded apps can have individual layers for each of its asynchronous operations. To create a custom layer, identify the section of code you would like to appear as a layer, and wrap it in a pair of entry and exit events as shown.

EntryTraceEvent event = <a href="#CreateEntryEvent">Trace.CreateEntryEvent("my_layer_name")</a>;
event.AddInfo("something", "interesting");
event.Report();
...
ExitTraceEvent event = <a href="#CreateExitEvent">Trace.CreateExitEvent("my_layer_name")</a>;
event.Report();
Two ways to create a layer

If you want to create a custom layer for a particular method, there are two ways to do this. The first is to wrap it in a pair of entry and exit events. But this technique becomes burdensome if the method is called more than once and you want to trace each of those calls. Instead, you can use the second way which is the TraceAttribute attribute class. Attribute classes are a convenient way of associating declarative information with program entities, in this case the method you want to trace. The syntax for associating the TraceAttribute with a method is shown below; try to declare the association as close to the method as reasonable, for example within the class just above the method definition. TraceAttribute requires one positional parameter, which must be the method name; the method name will also become the custom layer name. TraceAttribute accepts to two optional named parameters, see backtraces and return values for more on that.

class MyClass {
[TraceAttribute("AnnotatedMethodcharRef", Backtrace = true, ReturnValue = true)]
public void AnnotatedMethodcharRef(ref char value)
{
// your method definition goes here
}
}

Tracing multi-threaded applications

You may want to report events from background/child threads and associate them with the thread that spawned them. Assuming that a trace was already started in the parent thread:

  1. Pass the trace context to the child thread using TraceContext.GetCurrent().
  2. Set the context within the child thread using Trace.SetAsCurrent().
  3. Mark the thread as asynchronous by calling EntryTraceEvent.SetAsync() on the entry event of the child layer.
  4. Clean up the thread by calling TraceContext.ClearCurrentContext() before returning it to the threadpool.
System.Threading.Thread myThread = new System.Threading.Thread(this.DoSomeWork1);
myThread.Start(TraceContext.GetCurrent());

public void DoSomeWork1(object data)
{
  TraceContext currentContext = data as TraceContext;
  if(currentContext != null)
  {
    currentContext.SetAsCurrent();

    var asyncntryEvent = Trace.CreateEntryEvent("my_layer_name");
    asyncntryEvent.AddInfo("something", "interesting");
    asyncntryEvent.SetAsync();
    asyncntryEvent.Report();
    // Code that needs to be traced
    var exitEvent = Trace.CreateExitEvent("my_layer_name");
    exitEvent.AddInfo("something", "interesting");
    exitEvent.Report();
    TraceContext.ClearCurrent(); 
  }
}

Tracing across external layers

While instrumenting your code you might want to trace a request across processes or hosts. This can be done by passing the X-Trace ID between them.

  1. The client should call Trace.GetCurrentTraceId(), which returns either a string representing the current trace or an empty string if no trace is active.
  2. The client should then send the value to the remote process by any desired means, but probably via the X-Trace HTTP header.
  3. The remote process should read the identifier and input it to Trace.ContinueTrace().
  4. When the remote process is done, it should end the trace using Trace.EndTrace().
  5. The remote process should then report the end trace event using EndTraceEvent.ReportAndReturnTraceId(), which returns the trace id.
  6. The remote process should send the trace id back to the client by any means, but probably via the X-Trace HTTP header.
  7. The client should then associate the trace id with the next exit event that it reports by using ExitTraceEvent.AddEdge(), which links the client-side and remote-side events.

Collecting additional trace details

Any additional information you collect will be presented on the trace details page.

Backtraces and return values

Backtraces and return values may be included when you are creating a custom layer for an individual function by way of the TraceAttribute class. To include a backtrace in the entry event of the layer, set the backtrace parameter of the TraceAttribute class to ‘true’. To include a return value in the exit event of the layer, set ReturnValue to ‘true’.

Add info events

There are two reasons you might want to create an info event: the first is to simply to attach any meta data that may be of interest to you during later analysis of a trace. The other reason is to take full advantage of TraceView filtering capability. In short, you can classify extents by attaching a pre-defined set of specified key/value pairs. Then from the dashboard, you can filter for traces with that extent type. See special interpretation, for more on this. To add info to an extent, after creating the info event, call .AddInfo() on it one or more times as shown. In this case the information events are displayed on the raw span data tab on the trace details page. If all of the key/value pairs for special interpretation are present, the extent type is reflected in the span details tab.

InfoTraceEvent event = Trace.CreateInfoEvent("my_layer_name");
event.AddInfo("something", "interesting");
event.AddInfo("something_else", "also_interesting");
event.Report();
Report errors

Create an error event for an exception, including a backtrace. Error events are marked on the in the trace view 50x50_trans.png and corresponding information is in the errors panel.

try {
// your code that might throw an exception goes here ...
 } catch(exceptionType exception) {
    Trace.ReportException(exception);
    // the rest of your exception handler ...
}
.NET controller filter

.NET instrumentation supports these frameworks. If we don’t support your framework, add controller/action information by reporting an info event with the ‘controller’ and ‘action’ keys. Even if your framework doesn’t have a conventional notion of controllers and actions, you can still take advantage of this filtering capability by simply attaching whatever values that make sense to you. Instrumentation reports controllers/action data for MVC5 automatically, but for MVC3 and MVC4 instrumentation might need to be turned on explicitly, see SecurityTransparencyInstrumentation.

InfoTraceEvent event = Trace.CreateInfoEvent(null);
event.<a href="#AddInfo">AddInfo("Cont", "interesting")</a>;
event.AddInfo("Controller", "some_controller");
event.AddInfo("Action", "some_action");
event.Report();

.NET API reference

The following methods are provided by the .NET instrumentation public API. The API namespace is: ‘AppNeta.Instrumentation’.


    Trace.StartTrace()

    method
    Trace.StartTrace()
    description
    Create a new layer if a trace is already in progress or start a trace. This would typically be done when a new request enters your system. 9 times out of 10 your incoming requests are fielded by a webserver and so traces will be initiated there by our instrumentation. If you do need to start traces within your application code, note that the first layer is started automatically, you don’t need to add a entry event for it.
    returns
    An event that can be populated with key/value pairs and reported.
    parameters
    layerName
    The name of the highest layer. It is required and may not be null.
    history
    Introduced in version 1.4.0
    example
    StartTraceEvent event = Trace.StartTrace("my_layer_name");
    event.AddInfo('something', 'interesting');
    event.Report();
    
    notes
    • A start event initializes a trace which must ultimately be terminated by a corresponding end trace.
    • You may use .AddInfo() to attach key/value pairs for special interpretation, or to attach any other desired information.
    • This method does not report the event. It must be reported by invoking StartTraceEvent.Report().
    related methods

    Trace.ContinueTrace()

    method
    Trace.ContinueTrace()
    description
    Either creates a new layer if a trace is already in progress or continues a trace from an external layer. This method is used almost exclusively for tracing across external layers.
    returns
    An event that can be populated with key/value pairs and reported. This event is the entry of the extent added below the external layer.
    parameters
    layerName
    The name of the layer to be added below the existing layer. It is required and may not be null.
    traceId
    If your application receives requests from a higher layer, such as an instrumented web server, you’ll receive an identifier for that trace. This identifier, the X-Trace ID, must be provided to Trace.ContinueTrace(). See tracing across external layers.
    history
    Introduced in version 1.4.0
    example
    ContinueTraceEvent event= Trace.ContinueTrace("my_layer_name", xTraceID);
    event.AddInfo("something", "interesting");
    event.Report();
    
    notes
    • You may use .AddInfo() to attach key/value pairs for special interpretation, or to attach any other desired information.
    • This method does not report the event. It must be reported by invoking ContinueTraceEvent.Report().
    related methods

    Trace.EndTrace()

    method
    Trace.EndTrace()
    description
    End a trace.
    returns
    An event that can be populated with key/value pairs and reported. Similar to Trace.StartTrace(), most of the time requests will egress your application stack at your webserver and so our instrumentation will take care of ending traces. But you will need this method for tracing across external layers.
    parameters
    layerName
    The name of the highest layer. It is required, and must match the layer provided to Trace.StartTrace(), Trace.ContinueTrace(), or CreateEntryEvent().
    history
    Introduced in version 1.4.0
    example
    EndTraceEvent event= Trace.EndTrace("my_layer_name");
    event.AddInfo("something", "interesting");
    event.Report();
    
    notes
    • The is terminates a trace, which must have already been initialized by a Trace.StartTrace().
    • If a trace was already in progress when the matching Trace.StartTrace() was called, then then this call ends a trace without clearing the context.
    • If a trace was started by the matching Trace.StartTrace(), this call ends a trace and clears the trace context.
    • You may use .AddInfo() to attach key/value pairs for special interpretation, or to attach any other desired information.
    • This method does not report the event. It must be reported by invoking EndTraceEvent.report() or EndTraceEvent.ReportAndReturnTraceId().
    related methods

    Trace.CreateEntryEvent()

    method
    Trace.CreateEntryEvent()
    description
    Start a new layer. It’s up to you, the application developer, to decide how to segment your application modules and sub-systems into layers.
    returns
    An event that can be populated with key/value pairs and reported.
    parameters
    layerName
    Choose a name for the layer you are initiating. It is required and may not be null.
    history
    Introduced in version 1.4.0
    example
    EntryTraceEvent event = Trace.CreateEntryEvent("my_layer_name");
    event.AddInfo("something", "interesting");
    event.Report();
    
    notes
    • This method initializes a layer, which must be completed by creating a corresponding exit event.
    • You may use EntryTraceEvent.AddInfo() to attach key/value pairs for special interpretation, or to attach any other desired information.
    • This method does not report the event. It must be reported by invoking EntryTraceEvent.Report().
    • For an alternate method of creating custom layers see two ways to create a layer.
    related methods

    method
    Trace.CreateExitEvent()
    description
    Complete the specified layer.
    returns
    An event that can be populated with key/value pairs and reported.
    parameters
    layerName
    The name of the layer you provided in the corresponding entry event.
    history
    Introduced in version 1.4.0
    example
    ExitTraceEvent event = Trace.CreateExitEvent("my_layer_name");
    event.AddInfo("something", "interesting");
    event.Report();
    
    notes
    • The specified layer must already have a corresponding entry event.
    • You may use ExitTraceEvent.AddInfo() to attach key/value pairs for special interpretation, or to attach any other desired information.
    • This method does not report the event. It must be reported by invoking ExitTraceEvent.Report().
    related methods

    Trace.CreateInfoEvent()

    method
    Trace.CreateInfoEvent()
    description
    Info events enable you to report information in between the entry and exit events of a layer, particularly for special interpretation.
    returns
    An event that can be populated with key/value pairs and reported.
    parameters
    layerName
    The name of the layer to which key/value pairs will be added, as you specified it in the entry event. Set this parameter to null to use the current layer.
    history
    Introduced in version 1.4.0
    example
    InfoTraceEvent event = Trace.CreateInfoEvent("my_layer_name");
    event.AddInfo("something", "interesting");
    event.Report();
    
    notes
    • You may use ExitTraceEvent.AddInfo() to attach key/value pairs for special interpretation, or to attach any other desired information.
    • This method does not report the event. It must be reported by invoking InfoTraceEvent.Report().
    related methods

    Trace.ReportException()

    method
    Trace.ReportException()
    description
    Report an exception, including a backtrace.
    history
    Introduced in version 1.4.0
    example
    See report errors.
    notes
    • This is a convenience method that is equivalent to attaching error event key/value pairs as described in special interpretation.
    • Key/value pairs unrelated to special interpretation can be viewed in the raw span data tab on the trace details page.

    EntryTraceEvent.SetAsync()

    method
    EntryTraceEvent.SetAsync()
    description
    Declare the layer initiated by the entry event as asynchronous. See tracing multi-threaded applications for usage information.
    history
    Introduced in version 1.4.0
    example
    EntryTraceEvent event = Trace.CreateEntryEvent("my_layer_name");
    event.SetAsync();
    event.AddInfo("something", "interesting");
    event.Report();
    

    ExitTraceEvent.AddEdge()

    method
    ExitTraceEvent.AddEdge()
    description
    Associate an external layer with the current trace. See tracing across external layers for usage information.
    parameters
    traceId
    Use the return value from EndTraceEvent.ReportAndReturnTraceId().
    history
    Introduced in version 1.4.0
    example
    ExitTraceEvent event = Trace.CreateExitEvent("my_layer_name");
    event.AddEdge(traceId);
    event.Report();
    

    .AddInfo()

    method
    .AddInfo()
    description
    Attach information to events in the form of key/value pairs particularly for special interpretation, but also to attach any other desired information.
    history
    Introduced in version 1.4.0
    example
    See add info events.
    notes
    Duplicate keys are ignored, and keys may not be null.

    .Report()

    method
    .Report()
    description
    Use this method to report events, as they are not automatically reported upon creation.
    history
    Introduced in version 1.4.0
    example
    EntryTraceEvent event = Trace.CreateEntryEvent("my_layer_name");
    event.AddInfo("something", "interesting");
    event.Report();
    

    .Report()

    method
    EndTraceEvent.ReportAndReturnTraceId()
    description
    Report the end trace event and return the trace id. See tracing across external layers for usage information.
    history
    Introduced in version 1.4.0
    example
    EndTraceEvent event = Trace.EndTrace("my_layer_name");
    event.AddInfo("something", "interesting");
    string traceId = event.ReportAndReturnTraceId();
    
    related methods
    Trace.EndTrace()

    Trace.GetCurrentTraceId()

    method
    Trace.GetCurrentTraceId()
    description
    Get the current trace id, which can be passed to an external process. This method should not be used for any purpose other than for tracing across external layers.
    returns
    A string representing the current trace or an empty string if no trace is active.
    history
    Introduced in version 1.4.0

    TraceContext.GetCurrent()

    method
    TraceContext.GetCurrent()
    description
    Get the current trace id, which can be passed to a background/child thread. See tracing multi-threaded applications for usage information.
    returns
    A string representing the current trace or an empty string if no trace is active.
    history
    Introduced in version 1.4.0

    TraceContext.ClearCurrentContext()

    method
    TraceContext.ClearCurrentContext()
    description
    Unset the trace id before returning a thread back to the threadpool. See tracing multi-threaded applications for usage information.
    history
    Introduced in version 1.4.0

    TraceContext.SetAsCurrent()

    method
    TraceContext.SetAsCurrent()
    description
    Set the trace id for a background/child thread. See tracing multi-threaded applications for usage information.
    history
    Introduced in version 1.4.0

    Real user monitoring for .NET

    Do you have an instrumented webserver?

    These instructions involve enabling RUM via your layout file. If an instrumented webserver sits in front of your app, you don’t need to enable RUM here. It’s already provided at the web server level via our auto-rum support.

    TraceView provides optional javascript-based client-side performance data via real user monitoring (RUM). For .net a RUM wrapper assembly enables you to easily inject the required scripts into your web application.

    1. Copy the AppNeta.RUM.dll assembly from the agent install directory, i.e., C:\Program Files\AppNeta\TraceView\dotnet, include it in your solution, and add an assembly reference. The assembly is not installed onto the GAC during the installation of our .net agent, and has no dependencies on the .net agent. You may safely uninstall and upgrade your .net agent at any time, without any need to re-deploy your web application. By default, and when the instrumentation is not present, the RUM wrapper emits harmless empty html comments.

    2. Place the following code nuggets in Views\Shared_Layout.cshtml or Default.master—for ASP .NET MVC and ASP .NET respectively— and/or any other master template files in which the RUM js should be injected.

      1. Place the header code nugget just after any tags in your block. It should be the first non-meta tag inside.

        ASP.NET MVC (razor)
         @Html.Raw(AppNeta.RUM.Header()) HtmlHelper.Raw prevents RUM markup from being html-encoded.-->
        
        ASP.NET
         <%= AppNeta.RUM.Header() %>
        
      2. Place the footer code nugget immediately before the tag inside.

        ASP.NET MVC (razor)
         @Html.Raw(AppNeta.RUM.Footer())
        
        ASP.NET
         <%= AppNeta.RUM.Footer() %>
        
    3. Test your web application locally and view the page source in your browser. The page markup should include < !– RUM’s Header –> and <!– RUM’s Footer –>. These comments will be altered with javascript in your production environment.