Intercepting browser requests with Postman

If you are doing any kind of rest api development you probably have heard of Postman. Long story short, it is a Chrome extension which allows you to send http requests in a very easy and intuitive way. Apart from that (and many other features), it also allows you to intercept browser request. As this feature is very easy to overlook, here is a simple guide how to use it.
In the Postman window, click little satellite look-like button and toggle the “Interceptor” switch
Postman switch interceptor
Postman will ask you to install additional plugin called Postman Interceptor
Once you click “Install” you will be redirected to Chrome Web Store where you can add the plugin to the browser. After successful installation you will see additional icon in Chrome menu bar. Click it and toggle “Request capture” switch
When you go back to Postman and toggle again “Interceptor” button, it will be synchronized with Postman Interceptor plugin
and from now on, requests sent by browser will be visible in requests history
where you will be able to modify and resend them.

Intercepting browser requests with Postman

Generating PDB files with Resharper

The majority of the libraries developers use in their projects these days are open source. So in case something crashes inside third party library or you just want to know how it works, it is possible to get the PDB files from Microsoft Symbols Servers and debug it. If for some reasons PDB cannot be found on the servers, you can always grab the source code from GitHub and add to your project manually. Unfortunately when you use commercial libraries, it is impossible to do any of the previous steps. Luckily with Resharper you are able to generate PDB files from assembly and use it later in Visual Studio to debug it.
Let’s assume we would like to generate PDB files for EntityFramework. First of all, we have to locate EntityFramework assembly in Assembly Explorer. Go to Solution Explorer, RMB click on assembly you are interested in and select View in Assembly Explorer.
In Assembly Explorer once again RMB click on EntityFramework and select “Generate Pdb…
In the opened window, select the destination folder for the files.
Once you click “Generate“, Resharper will process the assembly and generate PDBs.
Once the files are generated we have to tell Visual Studio to use them. In order to do that, run the app and stop the execution with some breakpoint, then go to Debug->Windows-> Modules, locate EntityFramework.dll, click it with RMB, select “Load Symbols” and choose file(s) generated by Resharper.
A this point we have PDB files ready but we are not able to set any breakpoint as we don’t have source code of EntityFramework. Fortunately Resharper once again saves the day as it is able to navigate to decompiled sources. Just make sure that your settings (Resharper->Options->External Sources) are the same as in the picture below
and you can navigate to external libraries’ source code just like they were in your project. The very last step is to disable “Enable Just My Code” option in Tools->Options->Debugging->General
and from now on you can debug the external library

Generating PDB files with Resharper

Debugging cake scripts

We’ve been using Cake in our project for quite some time and it has been working great. However for time to time lack of debugging support was really annoying for me. Fortunately it seems that these times are gone now. During NDC Oslo 2016 Gary Ewan Park showed that it is possible to attach debugger to the build process. Here are the steps to achieve that. Let’s assume that we have following simple cake script.

In order to make the debugging possible it is necessary to add

preprocessor directive to the task we want the debugger to stop.

This operation doesn’t affect the default build process, so if you run in console

the build will run as usual. In order to be able to attach the debugger we have to call Cake with

flag. You can’t do it directly via

script so assuming that you didn’t change directory structure created by bootstrapper, go to Tools/Cake folder and run from PowerShell


is path to your cake script and

is task you want to start. Once you run the command, cake will wait for attaching the debugger
Now launch Visual Studio, go to Debug-> Attach to Process…, find process id listed in console
and click Attach. After couple of seconds Visual Studio will load your cake script and you will be able to debug it like normal application.

Debugging cake scripts

NLog – tracking flow of requests using MappedDiagnosticsLogicalContext

1. Problem

Everyone who has ever had to analyze logs from production environment knows, that quite often it is not an easy task. Usually application flow is deduced by log entries matched by thread id, which is problematic when you deal with multithreading scenarios. Say for example we have following piece of code

Default log file usually looks like that

Having multiple simultaneous Index requests, makes it almost impossible to figure out which log entry is part of which call. Fortunately with NLog it is possible to solve this problem without too much of a hassle.

2. Proposed solution

The whole idea is to leverage MappedDiagnosticsLogicalContext “storage” to keep some unique identifier of request for entire call. Note, that this identifier will be accessible also from other threads created from within given call. In order to set unique request id (also known as correlation id) I will use custom HttpModule. The very first implementation looks like that

Once the HttpModule is ready it is necessary to register it in web.config.

From now on, every request goes through LogginHttpModule and proper correlationId is set in MappedDiagnosticsLogicalContext.
As we want to have correlationId included in log files it is necessary to modify Nlog.config. In my case it looks like that

Note that we can access our correlationId variable via ${mdlc:item=correlationid}
Log file after the changes looks like that

This is almost perfect, however for some reasons correlationId is lost in EndRequest event handler. I am not sure if this is bug in NLog (I’ve posted question in Nlog’s github) or it is by design, however there is easy workaround for that. We can store our correlationId in HttpContext.Items collection and reassign it to MappedDiagnosticsLogicalContext in EndRequest event handler.

After these changes our log file finally looks OK

Source code for this post can be found here

NLog – tracking flow of requests using MappedDiagnosticsLogicalContext