JetBrains .NET Tools Blog

Did you know that you can run dotTrace Performance from the command line? Why would you want to run it from the command line? Maybe you want to share the same profiling configuration across the team? Maybe you want to run it as part of your build process? Maybe you want to run dotTrace as part of a larger testing process with other command line tools?

There are lots of reasons why you might want to run dotTrace Performance from the command line. Let’s look at how we can do exactly this.

Profiling from the command line is divided into two steps. First we create a configuration file that specifies the options we want to use. Next we launch dotTrace Performance using that profiling configuration file.

Creating a profiling configuration file

1. To create a profiling configuration file, open a command prompt and change to the dotTrace installation directory:
   cd c:\Program Files (x86)\JetBrains\dotTrace\v5.2\Bin\
2. Run Configuration2Xml.exe with the full path of the configuration file that you want to create:
   .\Configuration2Xml.exe <ConfigFilePath>
   For example:
   .\Configuration2Xml.exe c:\code\ProfilingConfiguration.xml
   N.B. Running Configuration2Xml.exe with an existing profiling configuration file will edit the file rather than overwriting it.
3. The Profile Application dialog will open. Select the type of application that you want to profile and click OK:
   
4. The Profiler Configuration dialog will open. Select the profiler options that you want to use and click Save:
   
5. Configuration2Xml.exe will create the specified profiling configuration XML file.
   

Profiling

1. To start profiling, run dotTraceProfiler.exe with the profiling configuration file:
   .\dotTraceProfiler.exe <ConfigFilePath>
   For example:
   .\dotTraceProfiler.exe c:\code\ProfilingConfiguration.xml
2. Once the application exits, a DTP file will be written in the current working directory, which can be opened and analyzed in dotTrace Performance.

For additional control of profiling, dotTraceProfiler.exe has a number of optional command line arguments:

• /showcontroller: Open the profile controller dialog where you can start/stop profiling, capture snapshots, and detach/kill the profiled process.
  
• /output=<OutputPath>: Specify the file name and/or directory where snapshots should be saved.
• /rawformat: Use an uncompressed snapshot format for faster processing and saving at the expense of increased file size.

dotTrace Performance can easily be orchestrated from the command line and integrated into your development process. Profile with pleasure!

You’ve got a thorny performance problem, but it only happens in your staging and production environments. For some reason, you just can’t seem to reproduce it on your local machine. What’s a developer to do? Fortunately dotTrace can profile a remote application and with dotTrace 5.2, it’s easier than ever before. Let’s walk through the steps of collecting a performance snapshot from a remote machine.

Step 1: Copy the dotTrace Remote Agent to the remote server

First we need some way for dotTrace to connect to the remote machine. This is done using the dotTrace Remote Agent, which ships with dotTrace. It can be found in:

C:\Program Files (x86)\JetBrains\dotTrace\v5.2\Bin\Remote

The contents of this directory are XCopy deployable. The target machine requires .NET 2.0 or greater installed. Simply copy the “.\Bin\Remote” directory to the remote server using RDP, file share, or any other file copy method of your choice.

Step 2: Run the dotTrace Remote Agent on the remote server

Log into the remote server and run RemoteAgent.exe. To profile an application running as a different user (e.g. ASP.NET web app running under IIS), shift-right-click RemoteAgent.exe and select “Run as administrator”. A console window similar to the one below will appear:

By default, the Remote Agent will listen on all network interfaces and both IPv4 and IPv6 protocols. Network traffic happens over HTTP and it defaults to port 9000. You can configure a variety of options if you need to change the defaults. Run `RemoteAgent.exe /?` for a full list of options. You will need to configure your firewall to allow TCP traffic on port 9000 (or whichever port you configured with the /port=VALUE option).

Step 3: Attach to the dotTrace Remote Agent from dotTrace on your local machine

Once the Remote Agent is running on the remote computer, you can connect to it from dotTrace running on your local machine using the “Attach To Process” button in dotTrace.

If you haven’t remotely profiled an application before, click on the “Profile on remote computer” link to bring up the Add Host dialog. If you have remotely profiled an application before, but not on this remote server, click the Add… button and enter the Remote Agent URL for that remote computer.

The Remote Agent URL will look like http://URL:PORT/RemoteAgent/AgentService.asmx. If you have connected to the remote computer before, it will be available in the drop down list.

Step 4: Profile the application

After the remote computer is selected, a list of .NET 4.0 and above processes will be displayed. Due to limitations of the .NET Profiler API, it is only possible to attach to processes running .NET 4.0 and above.

Choose whether you want to start profiling immediately or whether you would like to start with profiling disabled and click “Run”. The usual dotTrace profiling control dialog will appear. The only difference is that the performance data is being acquired on the remote computer.

Step 5: Get Snapshot and Analyze

Exercise the remote application in a way that demonstrates the performance problem and click “Get Snapshot”. The performance snapshot will automatically be downloaded to dotTrace and opened - ready for analysis.

You can analyze the snapshot data just as if you had recorded the snapshot locally. After determining the root cause and deploying a fix, you can repeat the process to collect another snapshot and verify that you have resolved the performance problem.

Profile with pleasure!

The ReSharper team here at JetBrains has added support for SharePoint and LightSwitch projects to ReSharper 7. Due to how these project types handle generated partial classes, previous versions of ReSharper displayed errors even though the project compiled successfully. By implementing support for these project types in ReSharper 7, ReSharper no longer displays spurious errors allowing developers to be more productive when using these project types. To see the improvements in action, let’s look at a SharePoint project and a LightSwitch project using ReSharper 6.1 and ReSharper 7.

Creating a SharePoint Site Definition project, ReSharper 6.1 displayed 3 errors in one file:

With ReSharper 7, that same project shows no errors:

ReSharper 7 now understands SharePoint-specific master pages, resources, style sheets, and JavaScript files, which dramatically reduces the number of false errors reported by ReSharper’s analysis engine.

If you open the LightSwitch Course Manager in Visual Studio, ReSharper 6.1 displayed 170 spurious errors across 16 files:

With ReSharper 7, no errors are displayed:

ReSharper 6.1 couldn’t locate partial methods or certain global LightSwitch-related classes such as User or Permissions:

ReSharper 7 can:

ReSharper 6.1 couldn’t locate model partial classes or base classes:

ReSharper 7 can:

Notice that ReSharper 7 provides quick-fixes for unused parameters, superfluous “this” usage, and all the other great features you expect from ReSharper. The SharePoint and LightSwitch enhancements in ReSharper 7 work for both C# and VB.NET projects. SharePoint and LightSwitch developers can now develop with pleasure too!