Debugging Release Builds

This is a nice little trick you might not know.

Lets say you have an application build in release
mode (/debug:pdbonly /optimize+) and you want to attach the debugger directly to a running instance.

To keep it simple, this is our app:

public partial class Window1 : Window
      {
          public Window1()
          {
              InitializeComponent();
          }

          private void button1_Click(object sender, RoutedEventArgs e)
          {
              Cal(100);
          }

          int Cal(int x)
          {
              return x * x;
          }
      }

We set a break point in this line and attach to the process:

return x * x;

But the debugger will never break in our code!

The reason is that the JIT compiler has inlined the method call (remember that will compiled with /optimize+)

This is indeed a good thing. In most cases, we want the JIT compiler to have the option to inline our production code.

We can see that the module is optimized in the modules window in VS:

 

Disable JIT Optimization

For debugging purposes, we can actually disable JIT Optimization without rebuilding the code.

Put an ini file (yes ini) in the same folder as the exe file. The filename should match the exe filename, just with ini as extension. In this case WpfApplication1.exe and WpfApplication1.ini.

The ini file should contain these 3 lines:

[.NET Framework Debugging Control]
GenerateTrackingInfo=1
AllowOptimize=0

This will tell the JIT compiler not to optimized the code, so the method-call won’t be inlined.

We can now see that the loaded module is not optimized:

Remember to disable “Enter Just My Code” in VS.NET (Tools –> Options –> Debugger)

Visual Studio 2008 Target Framework and .NET Service Packs

Visual Studio 2008 is a great product, but it would be nice to be able to compile against a specific .NET service pack. Let me illustrate,

Lets say that we have this .NET 2.0 application:

Everything runs fine on our server with .NET 2.0 installed.

Then we upgrade our project to VS2008 and set the target to .NET 2.0. We compile and everything is fine.

Until a developer uses some functionality from the .NET 2.0 SP1 API.
The source will compile, but fail at runtime since the server don’t have .NET 2.0 SP1 installed.

 

The problem is that we are compiling against .NET 2.0 SP1 and not .NET 2.0.

When we install VS2008, we get .NET 3.5 and .NET 2.0 SP1 and .NET 3.0 SP1. Using VS2008, there is no way to compile against a specific service pack.

So when using VS2008 to develop .NET 2.0 .NET apps, we need to ensure that we don’t use any functionality from .NET 2.0 SP1.

We can catch this during compile-time by using this FXCop rule. This rule will give the following warning/error depending on the settings.
 

By the way, we have the same issue when installing .NET 3.5 SP1. In that case, VS2008 will compile against .NET 2.0 SP2 / .NET 3.0 SP2, because these two service packs are included in .NET 3.5 SP1.