One thing that comes to me sometimes when I am debugging a program is to see a variable that has changed value, but I don’t know where and when it was changed. That leaded me to long and boring sessions of debugging, checking where the variable could have its changed.

I just wanted some kind of breakpoint that I could set that told me “break when this variable changes value”, but Visual Studio never had such a feature. Until now.

With .Net Core 3.0, Microsoft introduced a new feature in Visual Studio that will enhance a lot the debugging experience. The only drawback is that it only works with .Net Core 3.0 apps. But, nevertheless, it’s a great, long waited feature!

This feature is a little buried in Visula Studio (no, there is no right-click in a variable name with something like “break when this variable value changes”), so how do I set a data breakpoint?

To show this feature, I will use a .Net Core console app that gets the prime numbers:

static void Main(string[] args)
    if (args.Length < 1)
        Console.WriteLine("usage: GetPrimesLessThan <number>");

    if (!int.TryParse(args[0], out int number))
        Console.WriteLine("parameter should be a valid integer number");
    var primes = GetPrimesLessThan(number);
    Console.WriteLine($"Found {primes.Length} primes less than {number}");
    Console.WriteLine($"Last prime last than 10000 is {primes.Last()}");
private static int[] GetPrimesLessThan(int maxValue)
    if (maxValue <= 1)
        return new int[0];
    var primeArray = Enumerable.Range(0, maxValue).ToArray();
    var sizeOfArray = primeArray.Length;

    primeArray[0] = primeArray[1] = 0;

    for (int i = 2; i < Math.Sqrt(sizeOfArray - 1) + 1; i++)
        if (primeArray[i] <= 0) continue;
        for (var j = 2 * i; j < sizeOfArray; j += i)
            primeArray[j] = 0;

    return primeArray.Where(n => n > 0).ToArray();

This algorithm uses an array of integers that are set to zero if the number is not prime. At the end, all non prime numbers in the array are set to zero, so I can extract the primes with this linq line:

return primeArray.Where(n => n > 0).ToArray();

Let’s say that I want to know when the number 10 changes to 0. If I didn’t have this feature, I would have to follow the code, set breakpoints and analyze the data for every hit. Not anymore.

Here’s what must be done:

  • Set a breakpoint in the line just after the PrimeArray declaration
  • Run the code and let it break.
  • Open the Locals Window and expand the PrimeArray node
  • Right Click on the node with the value 10
  • Select Break when Value Changes

That’s it! You have set a data breakpoint for the value 10 in the array. Now let the code run, when the value changes, the code will break:

There you can analyze your code and see what has changed the variable. Nice, no?

This is a great feature and will enhance a lot my debugging, I’m glad that Visual Studio people could add it. I hope that you’ll enjoy it as much as I do.

The source code for the used project is at

When you have a multi-monitor device, you usually want to write code in one monitor and debug the program in another one. This is especially helpful when you want to debug some visual interface that is rendered by the code (or debug the Paint event, for WinForms apps).

But the program you’re debugging insists to open in the same monitor you are writing code. If you try to find some setting in Visual Studio to set the monitor to open the program, you won’t find any. So, what can be done in this case?

I’ve found two options, the code one, and the Windows one. Let’s start with the code option:

Add some code in the closing of the main form to save the window position and in the constructor of the form to restore the window position. This code could be used as a feature for your program: that way, the user can reposition and resize the window and the next time he opens it, it will be in the same position. If you don’t want this feature for the released version, enclose the code in the conditional compiler directive #if DEBUG ..#endif. You can check something like that for WPF in this CodeProject article: (things should be similar for WinForms). With this code, you can move the window to the other monitor and start debugging there. Just remember to close the app normally, to save the current position. The next time you will debug the program, the window it will be in the same place.

For UWP, saving the last window position is the default behavior, so you don’t have to do anything in the code: just move the window to the new position and close it normally and everything is set.

The Windows option is very simple, but not quite at sight: when you have a multi-monitor disposition, there is a checkbox in the display settings that says “Make this my main display”. All you have to do in this case is to right click the desktop of any monitor, select “ Display settings”, select the monitor you want to open your programs, check this box and voilà, all programs will open by default on the selected monitor. The only side effect in this case is that the search bar and the system tray will move to this monitor, but I think that this is minimal and does not affect my daily use. Easy, no?


That way, you can edit code in one screen and run the program in the other. So, happy debugging!

O Visual Studio 2015 introduziu novas ferramentas de debugging de UI para as aplicações WPF, Windows 8.1 ou Windows 10: a Live Visual Tree e o Live Property Explorer.

Com estas duas ferramentas, você pode examinar a interface que é gerada em tempo de execução e também ver os valores das propriedades dos elementos.

Uma coisa muito interessante é que você, além de poder examinar as propriedades, também pode alterá-las dinamicamente, avaliando como fica a interface – sem dúvida, isso é uma mão na roda para quem quer fazer experiências com a UI e ver por que algo não ficou exatamente como esperado!

Se você quer saber mais sobre isso, pode dar uma olhada em meu vídeo no Channel 9: