C#: automated method caller information via attributes

In C# there is a feature of the language that allows a method to receive as input parameters the member name, file path and line number of the calling method/property.

It is enough to add attributes to the method parameters receiving these values, as in the following example:

public void DoProcessing()
{
    TraceMessage("Something happened.");
}

public void TraceMessage(string message,
        [System.Runtime.CompilerServices.CallerMemberName] string memberName = "",
        [System.Runtime.CompilerServices.CallerFilePath] string sourceFilePath = "",
        [System.Runtime.CompilerServices.CallerLineNumber] int sourceLineNumber = 0)
{
    System.Diagnostics.Trace.WriteLine("message: " + message);
    System.Diagnostics.Trace.WriteLine("member name: " + memberName);
    System.Diagnostics.Trace.WriteLine("source file path: " + sourceFilePath);
    System.Diagnostics.Trace.WriteLine("source line number: " + sourceLineNumber);
}

You can see that this feature can be particular useful during tracing.

The example above has been taken from Caller Information (C# and Visual Basic).

PowerShell: edit and debug ps1 files in Visual Studio

In Visual Studio it's possible to edit and debug PowerShell scripts, using the PowerShell Tools for Visual Studio 2015 extension.

But even after installing the extension, debugging doesn't immediately work, as trying to do this, the output window simply shows an unauthorized access error message.

I've found the blog post PowerShell Tools for Visual Studio 2013 – unable to run and/or debug PowerShell script – execution policies problem that has helped me in finding the solution:

  • from a PowerShell window with elevated privileges,
  • run the command "Set-ExecutionPolicy" RemoteSigned

Visual Studio: managing NuGet packages in nested solutions

For one client I had to solve the problem of NuGet packages in nested solutions, where piratically there is one big solution file (used mainly by the build server) and many other nested solutions used by the various developer teams.

The solution in Nuget with multiple nested solutions simply works, but it uses an absolute path, so there can be issues when using the solutions from different machines (developer configurations, build server, and so on). The goal is to use relative paths.

Another long thread is Setting up a common nuget packages folder for all solutions when some projects are included in multiple solutions and it shows multiple alternative (even because meanwhile the tools has improved so many steps are no more necessary).

One example of configuration file can be downloaded here: NuGet.config (514B)

The only important things to note are:

  • the packages paths are relative to the .nuget folder


Visual Studio 2013: how test the performance of the html UI

As new solutions are pushing more and more the html UI, with various JavaScript and AJAX calls to complicate the scenario, analyzing the performance of the UI requires new tools.

For this, in Visual Studio 2013 you can find the HTML UI Responsiveness Profiler.


Here a few links on this topic: