DEV Community: Chebotov Nickolay

How to measure a method's performance in C# applications

Chebotov Nickolay — Sun, 12 Jan 2020 17:55:07 +0000

This How-To describes how to make the exact performance measurements of the public methods for public classes in your C# code and in the codes of the utilized libraries.

Unchase Fluent Performance Meter is an open-source and cross-platform .Net Standard 2.0 library that is designed for the method's performance measurement.

The library can be used in .NET Core and .NET Framework applications that support .Net Standard 2.0, and it allows for:

Making the exact performance measurements of the public methods for public classes in your code and in the codes of the utilized libraries (and recording the exact start and end times of the measurements);
Adding Custom Data to the measurement results. For example, the input parameters' values of the method and the result, or context of the method's execution, or corellationId, that can be used for linking several measurements of the methods' performance;
Splitting the measurement of the method performance into separate steps and storing personal data for each step. In addition, you can set the minimum execution time which will be used as a reference for saving the step into the measurement (if a step is completed faster, it will not be saved);
Excluding individual parts of the code from the performance measurement (for example, calls to the individual methods the execution time of which does not have to be saved for the measurement);
Adding custom Commands, which are guaranteed to be executed immediately at the end of the method's performance measurement (for example, to add post-processing of the obtained results, such as logging or writing data to the storage);
Adding custom Exception Handler for the code executed in the context of the method's performance measurement (can be used for all measurements, or for each measurement individually);
Setting the Cache Time for storing the method's performance measurement results after which they will be deleted;
Adding the info about the method's Caller to the measurement results which is possible by means of IHttpContextAccesor or specifying the Caller in the code (for example, you can specify the name of the external service that called the method);
Adding the info about the place where the performance measurement was started to the measurement results (referencing the file name and the exact line number where the method was called);
Aborting the method's performance measurement before the process is finished on its own.

The data obtained as a result of the method's performance measurement can be used to analyze the performance of the application (of its individual parts: both internal - native code, and external - the code of used libraries) and displayed in a graphical form convenient for you.

Table of content

Method's performance measurement
- Using DI to Get Performance measurement results (v2.1.0)
Method's performance measurement with DiagnosticSource (v1.1.0)
Method's performance measurement with WatchingPerformanceAttribute attribute (v2.0.0)
Measuring the performance of an external library method
Adding Custom Data and splitting into Steps
Excluding the measurement
Adding custom Commands and Actions
Adding Exception Handlers
Setting the Cache Time
Adding the info about the caller and call place origin (and aborting the measurement)

Getting started

To use the library, install NuGet package into your project:
Manually with the NuGet Package Manager:

Install-Package Unchase.FluentPerformanceMeter

Using the .NET CLI:

dotnet add package Unchase.FluentPerformanceMeter --version {version}

Where {version} is the version of the package you want to install. For example, dotnet add package Unchase.FluentPerformanceMeter --version 1.0.0

Examples of usage

Method's performance measurement

The following simple library usage example (without configuration and additional settings) meant to demonstrate how to measure a method's performance (Action) SimpleWatchingMethodStart for the Controller PerformanceMeterController in Asp.Net Core 2.2 WebAPI application. You can use the extension method .WatchingMethod().Start() or .StartWatching() for this.

Since v1.0.5, you can also use .WatchingMethod().Start(SimpleWatchingMethodStart) or .StartWatching(SimpleWatchingMethodStart) with the method name.

/// <summary>
/// Test GET method with simple performance watching.
/// </summary>
[HttpGet("SimpleWatchingMethodStart")]
public ActionResult SimpleWatchingMethodStart()
{   
    // for C# 8 you can use:
    //using var pm = PerformanceMeter<PerformanceMeterController>.StartWatching();

    using (PerformanceMeter<PerformanceMeterController>.WatchingMethod().Start())
    {
        // put your code with some logic here

        return Ok();
    }
}

To get the performance measurements results of public methods of the controller class PerformanceMeterController you can call the following method:

/// <summary>
/// Get methods performance info for this controller.
/// </summary>
/// <returns>Returns methods performance info.</returns>
[HttpGet("GetPerformanceInfo")]
[IgnoreMethodPerformance]
public ActionResult<IPerformanceInfo> GetPerformanceInfo()
{
    return Ok(PerformanceMeter<PerformanceMeterController>.PerformanceInfo);
}

The attribute IgnoreMethodPerformance is intended so that the method marked by it is not taken into account when measuring performance.

After calling the method SimpleWatchingMethodStart and calling GetPerformanceInfo we receive:

{
  "methodCalls": [
    {
      "methodName": "SimpleWatchingMethodStart",
      "elapsed": "00:00:00.0016350",
      "caller": "unknown",
      "startTime": "2019-12-06T10:27:27.3385385Z",
      "endTime": "2019-12-06T10:27:27.3401735Z",
      "customData": {},
      "steps": []
    }
  ],
  "totalActivity": [
    {
      "methodName": "SimpleWatchingMethodStart",
      "callsCount": 1
    }
  ],
  "currentActivity": [
    {
      "methodName": "SimpleWatchingMethodStart",
      "callsCount": 0
    }
  ],
  "uptimeSince": "2019-12-06T10:27:27.3370183Z",
  "className": "Unchase.FluentPerformanceMeter.TestWebAPI.Controllers.PerformanceMeterController",
  "methodNames": [
    "SimpleWatchingMethodStart"
  ],
  "customData": {},
  "timerFrequency": 10000000
}

Using DI to Get Performance measurement results

Starting with v2.1.0, it became possible to get the performance measurements results of public methods of the class using the built-in DI in ASP.NET Core application.
To do this, add the following code to Startap.cs:

public void ConfigureServices(IServiceCollection services)
{
    // ...

    // adds a singleton service to the specified IPerformanceInfo<MeasurableController> with DI
    services.AddSingleton(s => PerformanceMeter<MeasurableController>.PerformanceInfo);
    // ... the same for another classes (controllers)

    // ...
}

Then, using DI, you can get the results, for example, as follows:

[ApiController]
[Route("api/v1/[controller]")]
public class PerformanceMeterController : ControllerBase
{
    private readonly IPerformanceInfo<PerformanceMeterController> _performanceInfo;

    public PerformanceMeterController(IPerformanceInfo<PerformanceMeterController> performanceInfo)
    {
        _performanceInfo = performanceInfo;
    }

    // ...

    /// <summary>
    /// Get methods performance info for this controller.
    /// </summary>
    /// <returns>Returns methods performance info.</returns>
    [HttpGet("GetPerformanceInfoV2")]
    [IgnoreMethodPerformance]
    public ActionResult<IPerformanceInfo> GetPerformanceInfoV2()
    {
        return Ok(_performanceInfo);
    }

    // ...
}

Method's performance measurement with `DiagnosticSource`

Starting with v1.1.0, it became possible to measure the performance of methods in an AspNetCore MVC application using the DiagnosticSource and the special WatchingWithDiagnosticSourceAttribute attribute. To do this, add the NuGet package Unchase.FluentPerformanceMeter.AspNetCore.Mvc to the project and add the following code to Startap.cs:

public void ConfigureServices(IServiceCollection services)
{
    // ...

    // allows to measure methods performance for class "MeasurableClass" and "MeasurableSecondClass"
    services.AddPerformanceDiagnosticObserver<MeasurableClass>();
    services.AddPerformanceDiagnosticObserver<MeasurableSecondClass>();
    // ... the same for another classes
    services.AddMvc();
    // ...
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    // ...
    app.UsePerformanceDiagnosticObserver();
    app.UseMvc();
}

Then mark with the attribute WatchingWithDiagnosticSourceAttribute either individual methods:

[HttpGet("SimpleWatchingMethodStart")]
[WatchingWithDiagnosticSource]
public ActionResult SimpleWatchingMethodStart()
{   
    return Ok();
}

or the whole class:

[ApiController]
[Route("api/v1/[controller]")]
[Produces("application/json")]
[SwaggerTag("Unchase.PerformanceMeter Test WebAPI Controller")]
[WatchingWithDiagnosticSource]
public class PerformanceMeterController : ControllerBase
{
    // measurable methods
}

Starting with version v1.2.0, it became possible to add invocation arguments to custom method performance measurement data in an AspNetCore MVC application using the special AddMethodArgumentsToCustomDataAttribute attribute in conjunction with the WatchingWithDiagnosticSourceAttribute attribute:

[HttpPost("SimpleWatchingMethodStartWithArgs")]
[WatchingWithDiagnosticSource]
[AddMethodArgumentsToCustomData("actionArguments")]
public ActionResult SimpleWatchingMethodStartWithArgs(DTOArgument arg)
{
    return Ok();
}

After calling the method SimpleWatchingMethodStartWithArgs and calling GetPerformanceInfo we receive:

{
  "methodCalls": [
    {
      "methodName": "SimpleWatchingMethodStartWithArgs",
      "elapsed": "00:00:00.0016350",
      "caller": "unknown",
      "startTime": "2019-12-06T10:27:27.3385385Z",
      "endTime": "2019-12-06T10:27:27.3401735Z",
      "customData": {
        "actionArguments": {
          "arg": {
            "data": "<string_in_DTOArgument>"
          }
        }
      },
      "steps": []
    }
  ],
  "totalActivity": [
    {
      "methodName": "SimpleWatchingMethodStartWithArgs",
      "callsCount": 1
    }
  ],
  "currentActivity": [
    {
      "methodName": "SimpleWatchingMethodStartWithArgs",
      "callsCount": 0
    }
  ],
  "uptimeSince": "2019-12-06T10:27:27.3370183Z",
  "className": "Unchase.FluentPerformanceMeter.TestWebAPI.Controllers.PerformanceMeterController",
  "methodNames": [
    "SimpleWatchingMethodStartWithArgs"
  ],
  "customData": {},
  "timerFrequency": 10000000
}

Method's performance measurement with `WatchingPerformanceAttribute` attribute

Starting with v2.0.0, it became possible to measure the performance of methods (actions) in an AspNetCore MVC application using the special WatchingPerformanceAttribute attribute, as well as configure the methods performance watching for the controllers in Startup.cs. To do this, add the NuGet package Unchase.FluentPerformanceMeter.AspNetCore.Mvc to the project and add the following code to Startap.cs:

public void ConfigureServices(IServiceCollection services)
{
    // ...

    // allows to measure methods performance for class "MeasurableController" with configuring options
    services.AddPerformanceMeter<MeasurableController>(options => 
    {
        // ALL of this is optional. You can simply call .AddPerformanceMeter<MeasurableController>() for all defaults
        // Defaults: In-Memory for 5 minutes, everything watched, every user can see

        // excludes a method from performance watching
        options.ExcludeMethod(nameof(MeasurableController.MeasurableAction));

        // to control which requests are watched, use the Func<HttpRequest, bool> option:
        options.ShouldWatching = request => request.HttpContext.User.IsInRole("Dev");

        // allows to add custom data from custom attributes ("MethodCustomDataAttribute", "MethodCallerAttribute") to performance watching
        options.AddCustomDataFromCustomAttributes = false;

        // allows to use "IgnoreMethodPerformanceAttribute" for excluding from performance watching
        options.UseIgnoreMethodPerformanceAttribute = false;

        // allows to watch actions performance annotated with special attribute ("WatchingPerformanceAttribute")
        options.WatchForAnnotatedWithAttributeOnly = false;

        // excludes a path from being watched
        options.IgnorePath("/some_path");

        // allows to add route path to custom data (with "pm_path" key)
        options.AddRoutePathToCustomData = false;

        // set cache time for the watched performance results for the controller class
        options.SetMethodCallsCacheTime(5);

        // adds common custom data (anonymous class) to class performance information
        options.AddCustomData("Custom anonymous class", new { Name = "Custom Name", Value = 1 });

        // set default exception handler for the controller class
        options.SetDefaultExceptionHandler((ex) => Debug.WriteLine(ex.Message));
    });
    // ... and for "MeasurableSecondController" (without configuring options)
    services.AddPerformanceMeter<MeasurableSecondController>();
    // ... the same for another controllers

    services.AddMvc();

    // ...
}

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    // ...

    app.UseRouting();

    app.UseEndpoints(c =>
    {
        c.MapControllers();

        // use performance watching for concrete controller (for example, "MeasurableController")
        app.UsePerformanceMeterFor<MeasurableController>();
        // ... the same for another controllers
    });
}

Then mark with the attribute WatchingPerformanceAttribute either individual methods:

[HttpGet("SimpleWatchingMethodStartWatchingPerformanceAttribute")]
[WatchingPerformance]
public ActionResult SimpleWatchingMethodStartWatchingPerformanceAttribute()
{   
    return Ok();
}

or the whole class:

[ApiController]
[Route("api/v1/[controller]")]
[Produces("application/json")]
[SwaggerTag("Unchase.PerformanceMeter Test WebAPI Controller")]
[WatchingPerformance]
public class PerformanceMeterController : ControllerBase
{
    // measurable methods (actions)
}

Measuring the performance of an external library method

To measure the performance of a public method of a public class of a third-party library, you should explicitly specify the class itself and the name of its method:

[HttpGet("GetThreadSleepPerformance")]
public ActionResult<string> GetThreadSleepPerformance()
{
    using (PerformanceMeter<Thread>.WatchingMethod(nameof(Thread.Sleep)).Start())
    {
        Thread.Sleep(1000);
    }

    return Ok(PerformanceMeter<Thread>.PerformanceInfo.MethodCalls.FirstOrDefault(ta => ta.MethodName == nameof(Thread.Sleep))?.Elapsed);
}

The executed method will return:

"00:00:01.0033040"

You can get performance info related to calling this method through the call:

/// <summary>
/// Get methods performance info for Thread class.
/// </summary>
/// <returns>Returns Thread methods performance info.</returns>
[HttpGet("GetThreadPerformanceInfo")]
[IgnoreMethodPerformance]
public ActionResult<IPerformanceInfo> GetThreadPerformanceInfo()
{
    return Ok(PerformanceMeter<Thread>.PerformanceInfo);
}

In response to the call of this method you will see:

{
  "methodCalls": [
    {
      "methodName": "Sleep",
      "elapsed": "00:00:01.0033040",
      "caller": "unknown",
      "startTime": "2019-12-06T13:08:09.336624Z",
      "endTime": "2019-12-06T13:08:10.339928Z",
      "customData": {},
      "steps": []
    }
  ],
  "totalActivity": [
    {
      "methodName": "Abort",
      "callsCount": 0
    },
    ...
 ],
"currentActivity": [
    {
      "methodName": "Abort",
      "callsCount": 0
    },
    ...
 ],
"uptimeSince": "2019-12-06T13:08:09.3357028Z",
  "className": "System.Threading.Thread",
  "methodNames": [
    "Abort",
    ...
  ],
  "customData": {},
  "timerFrequency": 10000000
}

Adding Custom Data and splitting into Steps

You can add Custom Data for all methods' performance measurements of a particular class. Let's take the static constructor of the PerformanceMeterController controller class as an example:

[ApiController]
[Route("api/v1/[controller]")]
public class PerformanceMeterController : ControllerBase
{
    /// <summary>
    /// Static constructor.
    /// </summary>
    static PerformanceMeterController()
    {
        // add common custom data (string) to class performance information
        PerformanceMeter<PerformanceMeterController>.AddCustomData("Tag", "CustomTag");

        // add common custom data (anonymous class) to class performance information
        PerformanceMeter<PerformanceMeterController>.AddCustomData("Custom anonymous class", new { Name = "Custom Name", Value = 1 });
    }

    // ... actions
}

In addition, you can add Custom Data for a specific measurement using the extension method .WithSettingData.CustomData("<key>", <value>) (which can be also utilized through the special attribute MethodCustomDataAttribute) and for each Step of this measurement (that was added using the extension method .Step("<step_name>")) using the extension method .AddCustomData("<key>", <value>):

/// <summary>
/// Test GET method with simple performance watching (with steps).
/// </summary>
[HttpGet("SimpleStartWatchingWithSteps")]
[MethodCustomData("Custom data from attribute", "Attr")]
public ActionResult SimpleStartWatchingWithSteps()
{
    using (var pm = PerformanceMeter<PerformanceMeterController>
        .WatchingMethod()
        .WithSettingData
            .CustomData("coins", 1)
            .CustomData("Coins sets", new 
            { 
                Gold = "Many",
                Silver = 5
            })
        .Start())
    {
        // put your code with some logic here

        // add "Step 1"
        using (pm.Step("Step 1"))
        {
            Thread.Sleep(1000);
        }

        // add "Step 2" with custom data
        using (var pmStep = pm.Step("Step 2").AddCustomData("step2 custom data", "data!"))
        {
            // add "Step 3 in Step 2"
            using (pm.Step("Step 3 in Step 2"))
            {
                Thread.Sleep(1000);
            }

            // add custom data to "Step 2"
            pmStep.AddCustomData("step2 another custom data", "data2!");

            // get and remove custom data from "Step 2"
            var customData = pmStep.GetAndRemoveCustomData<string>("step2 custom data");
            // get custom data from "Step 2" (without removing)
            var anotherCustomData = pmStep.GetCustomData<string>("step2 another custom data");

            // ...
        }
    }
}

As a result, when GetPerformanceInfo is called we get:

{
  "methodCalls": [
    {
      "methodName": "SimpleStartWatchingWithSteps",
      "elapsed": "00:00:02.0083031",
      "caller": "unknown",
      "startTime": "2019-12-06T11:58:18.9006891Z",
      "endTime": "2019-12-06T11:58:20.9089922Z",
      "customData": {
        "Coins sets": {
          "gold": "Many",
          "silver": 5
        },
        "coins": 1,
        "Custom data from attribute": "Attr"
      },
      "steps": [
        {
          "stepName": "Step 1",
          "elapsed": "00:00:01.0009758",
          "startTime": "2019-12-06T11:58:18.9018272Z",
          "endTime": "2019-12-06T11:58:19.902803Z",
          "customData": {}
        },
        {
          "stepName": "Step 3 in Step 2",
          "elapsed": "00:00:01.0004549",
          "startTime": "2019-12-06T11:58:19.9046523Z",
          "endTime": "2019-12-06T11:58:20.9051072Z",
          "customData": {}
        },
        {
          "stepName": "Step 2",
          "elapsed": "00:00:01.0029596",
          "startTime": "2019-12-06T11:58:19.904534Z",
          "endTime": "2019-12-06T11:58:20.9074936Z",
          "customData": {
            "step2 another custom data": "data2!"
          }
        }
      ]
    }
  ],
  "totalActivity": [
    {
      "methodName": "SimpleStartWatchingWithSteps",
      "callsCount": 1
    }
  ],
  "currentActivity": [
    {
      "methodName": "SimpleStartWatchingWithSteps",
      "callsCount": 0
    }
  ],
  "uptimeSince": "2019-12-06T11:58:18.8801249Z",
  "className": "Unchase.FluentPerformanceMeter.TestWebAPI.Controllers.PerformanceMeterController",
  "methodNames": [
    "SimpleStartWatchingWithSteps"
  ],
  "customData": {
    "Tag": "CustomTag",
    "Custom anonymous class": {
      "name": "Custom Name",
      "value": 1
    }
  },
  "timerFrequency": 10000000
}

Excluding the measurement

You can exclude individual parts of the method's performance measurement (using .Ignore() or .Executing().WithoutWatching().Start(<Action>) extension methods), and also skip saving individual Steps (using .StepIf("<step_name>", <minSaveMs>) extension method), if they do not satisfy the condition (the step execution time will be taken into the method execution time):

using (var pm = PerformanceMeter<PerformanceMeterController>.WatchingMethod().Start())
{
    // put your code with some logic here

    // sleep 1 sec
    Thread.Sleep(1000);

    // ignore this block in performance watching
    using (pm.Ignore())
    {
        Thread.Sleep(5000);
    }

    // skip this step with minSaveMs (do not save the step results, but take into account its duration)
    using (pm.StepIf("Skipped step", minSaveMs: 1000))
    {
        Thread.Sleep(500);
    }

    // execute action without performance watching
    pm.Executing().WithoutWatching().Start(() => 
    {
        Thread.Sleep(2000);
    });

    return Ok();
}

As a result, we get:

{
  "methodCalls": [
    {
      "methodName": "SimpleStartWatchingWithIgnored",
      "elapsed": "00:00:01.5080227",
      "caller": "unknown",
      "startTime": "2019-12-06T12:34:36.9187359Z",
      "endTime": "2019-12-06T12:34:38.4267586Z",
      "customData": {},
      "steps": []
    }
  ],
  "totalActivity": [
    {
      "methodName": "SimpleStartWatchingWithIgnored",
      "callsCount": 1
    }
  ],
  "currentActivity": [
    {
      "methodName": "SimpleStartWatchingWithIgnored",
      "callsCount": 0
    }
  ],
  "uptimeSince": "2019-12-06T12:34:36.9035129Z",
  "className": "Unchase.FluentPerformanceMeter.TestWebAPI.Controllers.PerformanceMeterController",
  "methodNames": [
    "SimpleStartWatchingWithIgnored"
  ],
  "customData": { },
  "timerFrequency": 10000000
}

Adding custom Commands and Actions

To add a custom Command that will be guaranteed to be executed upon completion of the method's performance measurement, it is required to create a command class that will implement the IPerformanceCommand interface. In this case, you can transfer arbitrary data through the constructor of the created command that will be used when the command is executed. For example:

/// <summary>
/// Custom executed command.
/// </summary>
public class ExecutedCommand : IPerformanceCommand
{
    /// <summary>
    /// Executed commad name.
    /// </summary>
    public string CommandName => this.GetType().Name;

    private string _customString { get; }

    internal bool IsCommandExecuted { get; private set; }

    /// <summary>
    /// Constructor.
    /// </summary>
    /// <remarks>
    /// You can pass any data through the command constructor.
    /// </remarks>
    /// <param name="customString"></param>
    public ExecutedCommand(string customString) 
    {
        this._customString = customString;
    }

    /// <summary>
    /// Execute command.
    /// </summary>
    /// <param name="performanceInfo"><see cref="IPerformanceInfo"/>.</param>
    public void Execute(IPerformanceInfo performanceInfo)
    {
        // for example, write to the debug console some information
        Debug.WriteLine(this.CommandName);
        Debug.WriteLine(this._customString);
        Debug.WriteLine($"Method names count: {performanceInfo.MethodNames.Count}");
        this.IsCommandExecuted = true;
    }
}

You can add a custom Command (IPerformanceCommand) and an Action so that they are executed at the end of the measurement the following way:

// custom "ExecutedCommand" will be executed after performance watching is completed
using (PerformanceMeter<PerformanceMeterController>
    .WatchingMethod()
    .WithExecutingOnComplete
        .Command(new ExecutedCommand("bla-bla-bla"))
        .Action((pi) =>
        {
            Debug.WriteLine($"Class name: {pi.ClassName}");
        })
    .Start())
{
    return Ok();
}

As a result, at the end of the measurement the Debug console will display:

ExecutedCommand
bla-bla-bla
Method names count: 13
Class name: Unchase.FluentPerformanceMeter.TestWebAPI.Controllers.PerformanceMeterController

Adding Exception Handlers

If you need to handle exceptions that may occur during the execution of a part of the method for which performance is measured, you need to add an Exception Handler as follows:

using (var pm = PerformanceMeter<PerformanceMeterController>.StartWatching())
{
    // execute an action that throws the exception to be handled by the exception handler
    pm.Executing()
        .WithExceptionHandler((ex) => Debug.WriteLine(ex.Message))
        .Start(() => throw new Exception("Exception"));

    // execute action throws custom Exception with exception handler
    pm.Executing<CustomException>()
       .WithExceptionHandler((ex) => { Debug.WriteLine(ex.Message); })
       .Start(() =>
       {
           throw new CustomException("Custom exception was occured!");
       });

    return Ok();
}

Where the CustomException class is (for example):

/// <summary>
/// Custom exception.
/// </summary>
public class CustomException : Exception
{
    public CustomException(string message) : base(message) { }

    public CustomException(string message, Exception innerException) : base(message, innerException) { }

    public CustomException() { }
}

As a result, the following will be displayed in the Debug console:

Exception
Custom exception was occured!

In addition, you can specify an Exception Handler that will be used by default to measure the performance of any method of the given class, for example, through the static constructor of the PerformanceMeterController controller class:

[ApiController]
[Route("api/v1/[controller]")]
public class PerformanceMeterController : ControllerBase
{
    /// <summary>
    /// Static constructor.
    /// </summary>
    static PerformanceMeterController()
    {
        // set default exception handler for PerformanceMeterController class
        PerformanceMeter<PerformanceMeterController>.SetDefaultExceptionHandler((ex) => Debug.WriteLine(ex.Message));
    }

    // ... actions
}

Setting the Cache Time

You can set the Cache Time for storing the results of the method's performance measurement, after which these results will be deleted. For each class that is to be measured, this time is set separately. For example, the time can be set through the static constructor of the PerformanceMeterController controller class:

[ApiController]
[Route("api/v1/[controller]")]
public class PerformanceMeterController : ControllerBase
{
    /// <summary>
    /// Static constructor.
    /// </summary>
    static PerformanceMeterController()
    {
        // set cache time for PerformanceMeterController class
        PerformanceMeter<PerformanceMeterController>.SetMethodCallsCacheTime(5);
    }

    // ... actions
}

Adding the info about the caller and call place origin (and aborting the measurement)

You can specify who is calling the method using the extension method .CallerFrom("<caller_name>") (either a string value or IHttpContextAccessor is passed to it) or a special attribute [MethodCaller ("<caller_name>")] for the method. Moreover, if both the attribute and the extension method are used, then the value will be taken from the latter.
To add a call source for a performance measurement, use the extension method .WithSettingData.CallerSourceData().
To stop/abort the performance measurement inside the using block, use the .StopWatching() extension method or the Dispose() method directly:

[HttpPost("StartWatchingWithCallerName")]
[MethodCaller("testCaller")]
public ActionResult<string> StartWatchingWithCallerName([FromBody] string value)
{
    // the method's performance info will be amended with the caller's name (if internal HttpContextAccessor is null)
    using (var pm = PerformanceMeter<PerformanceMeterController>
        .WatchingMethod()
        .WithSettingData
            .CallerSourceData()
            .CallerFrom("Test caller")
        .Start())
    {
        pm.StopWatching(); // stop watching here (or you can use "pm.Dispose();")
        Thread.Sleep(2000);

        return Ok(value);
    }
}

As a result of calling the GetPerformanceInfo method, you will get:

{
  "methodCalls": [
    {
      "methodName": "StartWatchingWithCallerName",
      "elapsed": "00:00:00.0019172",
      "caller": "Test caller",
      "startTime": "2019-12-06T13:35:45.3164507Z",
      "endTime": "2019-12-06T13:35:45.3183679Z",
      "customData": {
        "customData123": 123,
        "callerSourceLineNumber": 525,
        "callerSource": "D:\\GitHub\\Unchase.FluentPerformanceMeter\\Unchase.FluentPerformanceMeter.TestWebAPI\\Controllers\\PerformanceMeterController.cs"
      },
      "steps": []
    }
  ],
  "totalActivity": [
    {
      "methodName": "StartWatchingWithCallerName",
      "callsCount": 1
    }
  ],
  "currentActivity": [
    {
      "methodName": "StartWatchingWithCallerName",
      "callsCount": 0
    }
  ],
  "uptimeSince": "2019-12-06T13:35:45.2601668Z",
  "className": "Unchase.FluentPerformanceMeter.TestWebAPI.Controllers.PerformanceMeterController",
  "methodNames": [
    "StartWatchingWithCallerName"
  ],
  "customData": { },
  "timerFrequency": 10000000
}

Enjoy programming with Unchase!

How to generate early-bound C# or Visual Basic (or C++) classes used by Dynamics 365 for Customer Engagement

Chebotov Nickolay — Fri, 01 Nov 2019 09:24:41 +0000

This How-to describes how to generate early-bound C# or Visual Basic (or C++) classes that represent the entity data model used by Dynamics 365 for Customer Engagement with Unchase Dynamics365 Connected Service to Visual Studio 2017/2019 projects.

Generate entity classes

The Connected Service creates a Microsoft Visual C# or Visual Basic .NET (or C++) output file that contains strongly-typed classes for entities in your organization. This includes custom entities and attributes. This output file contains one class for each entity, providing early binding and IntelliSense support in Visual Studio to aid you as you write code.

The generated classes are partial classes that can be extended with custom business logic in separate files.

Generate an OrganizationServiceContext class

The Connected Service can also be used to generate a class derived from the OrganizationServiceContext class that acts as an entity container in the entity data model. This service context provides the facilities for tracking changes and managing identities, concurrency, and relationships.

This class also exposes a SaveChanges() method that writes inserts, updates, and deletes records in Common Data Service.

For more information, see Use OrganizationServiceContext.

Use generated classes

The classes created by the Connected Service are designed to be built into a class library that can be referenced by projects that use Common Data Service. After you have generated the class file using the Connected Service, you must also add references to several assemblies that the generated classes are dependent upon.

The following lists assemblies that must be referenced in your project when you use the generated code file.

Microsoft.Crm.Sdk.Proxy.dll
Microsoft.Xrm.Sdk.dll

These assemblies are part of the Microsoft.CrmSdk.CoreAssemblies NuGet package. Use this Nuget packages to add these assemblies to your Visual Studio project.

Follow 4 steps to achieve this.

Step 1. Install the Connected Service

Launch the installed Visual Studio 2017/2019. Open the menu to manage Visual Studio extensions:

For Visual Studio 2017: Tools -> Extensions and Updates...

For Visual Studio 2019: Extensions -> Manage Extensions

Choose Online -> Visual Studio Marketplace tab. In search field type unchase, then install Unchase Dynamics365 Connected Service (just click Download button):

After all, restart the Visual Studio to install the Connected Service.

Step 2. Open the Connected Service wizard for Visual Studio project

Open the Visual Studio solution with project to generate client code in. In Solution Explorer make right-click on Connected Services or Dependencies item in the project for which you need to generate client code, and click on Add Connected Service:

Then choose Unchase Dynamics365 Connected Service to show the Connected Service wizard:

Step 3. Configure Dynamics 365 organization service endpoint

In the first page of the wizard you need to configure some necessary options:

Generating Language option - the language to generate the code in. C# or Visual Basic or C++;
Service name - the name of the folder (after generation) in Connected Service directory in the project (by default, if field is empty - Dynamics365Service);
Dynamics 365 service URI - The URI for the Organization service endpoint (URL or local file).

After setting the necessary options, you can immediately start connecting to the organization endpoint to generate the code by clicking the Finish button. In this case, there will choose default code generation options.

If you find a bug in the Connected Service, you can use the "Report a bug" button.

There are a few optional options you can specify before start generation process:

Additional Generation Options

Namespace - the namespace for the generated code. The default namespace is the global namespace;
Generated code file name prefix - the file name prefix for the generated code ('Generated' will be added after this);
Service Context Name - the name for the generated service context class. If a value is passed in, it will be used for the Service Context. If no value is supplied, no service context is created);
Generate messages checkbox - generate messages;
Message Namespace - namespace of messages to generate;
Generate wrapper classes for custom actions checkbox - generate request and response classes for custom actions;
Enable Generation Tracing checkbox - it is may take much more additional minutes. It is recommended to use when errors occur;
Add client NuGet-package before generation checkbox - allows automatically add Microsoft.CrmSdk.CoreAssemblies NuGet package to the client project;
Open generated files on complete in IDE checkbox - allows automatically open the generated files in IDE after generation process.

Connecting to the CRM

There are several ways to connect to the CRM:

Interactive Login - when used, a dialog to log into the Common Data Service is displayed. All other connection related parameters specified on the Connected Service options are ignored;

Connection String - contains information, provided as a single string, for connecting to a Common Data Service organization. All other connection related parameters specified on the Connected Service options are ignored;

For more information see Use connection strings in XRM tooling to connect to Common Data Service.

Authentication Credentials - connecting to the server for authentication with:
- Use OAuth checkbox - try to login with oAuth to CRM Online;
- UserName - the user name to use when you connect to the server for authentication;
- Password - the password to use when you connect to the server for authentication;
- Domain - the domain to authenticate against when you connect to an on-premises server.

Step 4 (Optional). Create Connected Service extensions

You can also create extensions and use it in this tool.

1) Create a .NET Framework 4.7.2 library project;

2) Add Unchase.Dynamics365.Customization NuGet package to your project;

3) Add a custom public class that implements one of interfaces from NuGet package:

ICustomizeCodeDomService - called after the CodeDOM generation has been completed, assuming the default instance of ICodeGenerationService. It is useful for generating additional classes, such as the constants in picklists;
ICodeWriterFilterService - called during the process of CodeDOM generation, assuming the default instance of ICodeGenerationService, to determine whether a specific object or property should be generated;
ICodeWriterMessageFilterService - called during the process of CodeDOM generation, assuming the default instance of ICodeGenerationService, to determine whether a specific message should be generated. This should not be used for requests/responses as these are already generated in Microsoft.Crm.Sdk.Proxy.dll and Microsoft.Xrm.Sdk.dll;
IMetadataProviderService - called to retrieve the metadata from the server. This may be called multiple times during the generation process, so the data should be cached;
IMetaDataProviderQueryService;
ICodeGenerationService - core implementation of the CodeDOM generation. If this is changed, the other extensions may not behave in the manner described;
INamingService - called during the CodeDOM generation to determine the name for objects, assuming the default implementation.

The following sample code demonstrates how to write an extension:

using System;
using System.Threading.Tasks;
using Microsoft.Xrm.Sdk.Metadata;
using Unchase.Dynamics365.Customization;

namespace TestDynamics
{
    /// <summary>
    /// Sample extension for the "Unchase Dynamics365 Connected Service" that generates early-bound
    /// classes for custom entities.
    /// </summary>
    public sealed class BasicFilteringService : ICodeWriterFilterService
    {
        public BasicFilteringService(ICodeWriterFilterService defaultService)
        {
            this.DefaultService = defaultService;
        }

        private ICodeWriterFilterService DefaultService { get; set; }

        public async Task<bool> GenerateAttributeAsync(AttributeMetadata attributeMetadata, IServiceProvider services)
        {
            return await this.DefaultService.GenerateAttributeAsync(attributeMetadata, services);
        }

        public async Task<bool> GenerateEntityAsync(EntityMetadata entityMetadata, IServiceProvider services)
        {
            if (!entityMetadata.IsCustomEntity.GetValueOrDefault()) { return false; }
            return await this.DefaultService.GenerateEntityAsync(entityMetadata, services);
        }

        public async Task<bool> GenerateOptionAsync(OptionMetadata optionMetadata, IServiceProvider services)
        {
            return await this.DefaultService.GenerateOptionAsync(optionMetadata, services);
        }

        public async Task<bool> GenerateOptionSetAsync(OptionSetMetadataBase optionSetMetadata, IServiceProvider services)
        {
            return await this.DefaultService.GenerateOptionSetAsync(optionSetMetadata, services);
        }

        public async Task<bool> GenerateRelationshipAsync(RelationshipMetadataBase relationshipMetadata, EntityMetadata otherEntityMetadata, IServiceProvider services)
        {
            return await this.DefaultService.GenerateRelationshipAsync(relationshipMetadata, otherEntityMetadata, services);
        }

        public async Task<bool> GenerateServiceContextAsync(IServiceProvider services)
        {
            return await this.DefaultService.GenerateServiceContextAsync(services);
        }
    }
}

4) Build the project so that the output dll file is created;

5) Browse created dll file with one or all classes that implements interfaces to add them into generation process:

Enjoy programming with Unchase!

How to generate C# or TypeScript client code for OpenAPI (Swagger) specification

Chebotov Nickolay — Mon, 14 Oct 2019 21:51:27 +0000

This How-To describes how to generate C# or TypeScript client code for OpenAPI (Swagger) specification with Unchase OpenAPI (Swagger) Connected Service to Visual Studio 2017/2019 projects.

The Unchase OpenAPI (Swagger) Connected Service is a Visual Studio 2017/2019 extension to generate C# (TypeScript) HttpClient (or C# Controllers) code for OpenAPI (formerly Swagger) web services with NSwag. Simply put, it is like kind old Add Service Reference for WCF or Add Web Reference for WSDL, but for JSON (YAML) API with customization of code generation like in NSwagStudio.

Follow *4 steps below to achieve this:

Step 1. Install the Connected Service

Launch the installed Visual Studio 2017/2019. Open the menu to manage Visual Studio extensions:

For Visual Studio 2017: Tools -> Extensions and Updates...

For Visual Studio 2019: Extensions -> Manage Extensions

Choose Online -> Visual Studio Marketplace tab. In search field type unchase, then install Unchase OpenAPI (Swagger) Connected Service (just click Download button):

After all, restart the Visual Studio to install the Connected Service.

Step 2. Open the Connected Service wizard for Visual Studio project

Then choose Unchase OpenAPI (Swagger) Connected Service to show the Connected Service wizard:

Step 3. Configure OpenAPI specification endpoint

In the first page of the wizard you need to configure some necessary options:

Service name - the name of the folder for generated files (by default, if field is empty - OpenAPIService);
Generated file name - the name of the generated files prefix (by default, if field is empty - OpenAPI);
OpenAPI (Swagger) specification URI (path) - the specification URI (URL or local file);
One or few of Generate CSharp Client, Generate TypeScript Client, Generate CSharp Controller - to generate C# (TypeScript) client code or/and C# Controllers code file(s) for OpenAPI specification. When you check a checkbox, the corresponding tab item with additional generation settings is added to the wizard:

After setting the necessary options, you can immediately start generating the code files by clicking the Finish button. In this case, there will choose default code generation options.

There are a few optional options you can specify before start generation process:

In the Runtime and variables section - the same options as in NSwagStudio:

Copy OpenAPI (Swagger) json-specification to nswag-file checkbox - the same as Create local Copy button in NSwagStudio:

Open generated files on complete in IDE checkbox - allows automatically open the generated files in IDE in generation process;
If you need to set network credentials for connecting to the endpoint (specification file), you should specify options in the Network Credentials section. If your network used Proxy, you should specify options in the Web Proxysection:

Step 4 (Optional). Configure code generation options

If you want to specify some options for generating code, just need to go to generation settings tab(s):

There are the same options like in NSwagStudio.

Enjoy programming with Unchase!

How to generate C# or Visual Basic client code for OData protocol versions 1.0–4.0

Chebotov Nickolay — Mon, 14 Oct 2019 21:51:22 +0000

This How-To describes how to generate C# or Visual Basic client code for OData protocol versions 1.0–4.0 with Unchase OData Connected Service to Visual Studio 2017/2019 projects.

The Unchase OData Connected Service is a Visual Studio 2017/2019 extension to generate C# (Visual Basic) client code for OData web services. Simply put, it is like kind old Add Service Reference for WCF or Add Web Reference for WSDL, but for OData protocol versions 1.0–4.0.

Follow 4 steps below to achieve this:

Step 1. Install the Connected Service

Launch the installed Visual Studio 2017/2019. Open the menu to manage Visual Studio extensions:

For Visual Studio 2017: Tools -> Extensions and Updates...

For Visual Studio 2019: Extensions -> Manage Extensions

Choose Online -> Visual Studio Marketplace tab. In search field type unchase, then install Unchase OData Connected Service (just click Download button):

After all, restart the Visual Studio to install the Connected Service.

Step 2. Open the Connected Service wizard for Visual Studio project

Then choose Unchase OData Connected Service to show the Connected Service wizard:

Step 3. Configure OData metadata endpoint

In the first page of the wizard you need to configure some necessary options:

Generating Language - C# or Visual Basic client code generation option;
Service name - the name of the folder (after generation) in Connected Service directory in the project (by default, if field is empty - OData Service);
OData metadata URI (path) - the metadata endpoint URI (URL or local file).

After setting the necessary options, you can immediately start generating the code files by clicking the Finish button. In this case, there will choose default code generation options.

If you find a bug in the Connected Service, you can use the "Report a bug" button.

There are a few optional options you can specify before start generation process:

Load from 'Connected Service.json' button - allows load client code generation parameters from json-file generated by Unchase OData Connected Service or OData Connected Service by Microsoft;
Open generated files on complete in IDE checkbox - allows automatically open the generated files in IDE in generation process;
Accept all untrusted certificates checkbox - allows to accept all untrusted certificates when connecting to the services;
If you need to set network credentials for connecting to the endpoint (metadata file), you should specify options in the Network Credentials section. If your network used Proxy, you should specify options in the Web Proxy section:

Step 4 (Optional). Configure code generation options

If you want to specify some options for generating code, just need to go to generation settings tab(s):

Common OData protocol versions 1.0–4.0 Advanced Settings wizard page settings:

There you can specify generated client code file name.

OData protocol versions 1.0–3.0 Advanced Settings wizard page setting in AdvancedSettings link:

If you check Select OData methods from FunctionImports (V3) or OperationImports (V4), the wizard page (tab) named Operation Imports Settings will be added where you can select the necessary methods that will be added after generation:

OData protocol version 4.0 Advanced Settings wizard page setting in AdvancedSettings link:

Enjoy programming with Unchase!

DEV Community: Chebotov Nickolay

How to measure a method's performance in C# applications

Table of content

Getting started

Examples of usage

Method's performance measurement

Using DI to Get Performance measurement results

Method's performance measurement with DiagnosticSource

Method's performance measurement with WatchingPerformanceAttribute attribute

Measuring the performance of an external library method

Adding Custom Data and splitting into Steps

Excluding the measurement

Adding custom Commands and Actions

Adding Exception Handlers

Setting the Cache Time

Adding the info about the caller and call place origin (and aborting the measurement)

How to generate early-bound C# or Visual Basic (or C++) classes used by Dynamics 365 for Customer Engagement

Generate entity classes

Generate an OrganizationServiceContext class

Use generated classes

Step 1. Install the Connected Service

Step 2. Open the Connected Service wizard for Visual Studio project

Step 3. Configure Dynamics 365 organization service endpoint

Additional Generation Options

Connecting to the CRM

Step 4 (Optional). Create Connected Service extensions

How to generate C# or TypeScript client code for OpenAPI (Swagger) specification

Step 1. Install the Connected Service

Step 2. Open the Connected Service wizard for Visual Studio project

Step 3. Configure OpenAPI specification endpoint

Step 4 (Optional). Configure code generation options

How to generate C# or Visual Basic client code for OData protocol versions 1.0–4.0

Step 1. Install the Connected Service

Step 2. Open the Connected Service wizard for Visual Studio project

Step 3. Configure OData metadata endpoint

Step 4 (Optional). Configure code generation options

Method's performance measurement with `DiagnosticSource`

Method's performance measurement with `WatchingPerformanceAttribute` attribute