A SourceTree lover sees Visual Studio catching up

Background

This was supposed to be a post about features that I find important for the daily work I do that the git gui SourceTree has and that Visual Studio's git tool lacks. But instead I learned that Visual Studio is catching up with its Visual Studio 2019 16.10 Preview 2.1 release!

File change preview for historic commits

Navigating the commit history and looking at file changes in Visual Studio is a pain, but today I downloaded Visual Studio 2019 16.10 Preview 2.1 and explored the news in its git tool. Looking at changes in historic commits is no longer a pain!

I also learned that Visual Studio can show diffs as inline or side-by-side.

SourceTree shows all branches in history

In SourceTree you see ALL branches by default, which is the way I like it because I get the full latest commit history context immediately. This isn't possible in Visual Studio, you have to select the branch that has the latest commit to be able to see the history for all branches.

If you ever would like to not see all branches in SourceTree, you can easily turn it off by selecting Current Branch in the dropdown, like this.

To show all branches is a feature under review by Microsoft 

https://developercommunity.visualstudio.com/t/how-do-i-view-the-history-of-all-branches-in-git/934801

Merges are shown better in SourceTree

I find the branch history tree to be more clear in SourceTree. Compare these two images that pictures a branch branched off of master, and then the branch is merged back to master.

In SourceTree it looks just like that, a branch going out from master and then coming back to master.

In Visual Studio it looks like a branch has been branched off from master, but then it looks like master has been merged to the branch!? When merging, the merge commit has two parents instead of one. There is a primary parent (the branch merged to) and a secondary parent (the branch merged from) and VS seems to mix them up.

I added a ticket regarding this.

But the image below, taken from this ticket hints about a rewrite of the the commit history tree visualization in VS. No merge is shown, but the tree looks different, and hopefully it will be easier to follow.

SourceTree auto-adds commits message for merge with conflicts

When doing a merge and the merge results in conflicts, a commit message like this the one below is added automatically by SourceTree. Visual Studio adds nothing. 

Merged ‘master’ into 'a_feature_branch'. Conflicts: # Foo.h # Bar.cpp

To be able to see which files that have had conflicts can be of help when you know that a feature has been added in a file, but that feature suddenly is gone or is buggy, because it probably disappeared in a manual merge conflict resolution that went wrong.

This also seems to be a feature under review.

https://developercommunity.visualstudio.com/t/VS2019-auto-populate-git-merge-commit-me/586587

In SourceTree you can pull a branch that isn't currently active

Yes, you can, and I thought it was something that made my branch handling smoother, but when writing this I can't come up with a scenario where it is needed.

Convert breakpoints to tracepoints when debugging multi-threaded apps in Visual Studio

Breaking the code execution on a breakpoint when debugging a multi-threaded application might change the execution flow of the different threads so much that you get a totally different scenario than you will have in production.

This problem can be remedied by converting breakpoints to tracepoints. A tracepoint can write text to the Output window and continue execution without stopping.

Set a tracepoint by first setting a breakpoint, right click it and select "Actions".

The message to be logged can contain predefined variables like
$CALLER - Name of the function calling the current function
$FUNCTION - Name of the current function
$TID - ID of the current thread

You can also get the value of a variable by using curly braces, like this: {variable_name}

When a breakpoint has been changed to a tracepoint the red bullet is changed to a diamond.

One call to the method in the image above results in this text being logged:

In MineSweeper.Program.TryParseDirection(string, out MineSweeper.Direction), called with directionStr = "S"

Alter template for "Create and initialize field" in Visual Studio to get fields prefixed with underscore

I've got a fresh installation of Visual Studio and this time I haven't added Resharper. And so far I don't miss it! I haven't been hammering out that much code, but it seems like the built in code assistent in Visual Studio has become way better, because I usually, almost immediately, greatly miss the extra help I get from Resharper.

What I've already found though, is that its auto generation of fields from parameters to the constructor needs some tweaking. Well, if you like to prefix your fields with an underscore that is.

In case you didn't know, you can position the marker on a new constructor parameter and press "Ctrl + ." to open up the Quick Actions and Refactorings menu.
Then you can choose to Create and initialize field and get presented with a preview of what the result will look like.
The images below shows what it looks like with the default setting.

Visual Studio automatically creates the field "arg1" and assigns it with the constructor parameter.

I prefer fields to be prefixed with underscore to make it possible to immediately distinguish fields from local variables when reading the code, which I think is a great help when trying to get a grip of what the code does. And it seems to be the standard for .net core.

To change the template for this, go to 

Tools -> Options -> Text Editor -> C# -> Code Style -> Naming

Click Manage naming styles. Add a naming style like the one below.

Add a new row by clicking the plus. 

Select Private or Internal Field as Specification.

Select your new naming style as the Required Style.

Click OK. 

I had to restart Visual Studio make the update work.

Now it looks like this:

And the result is:

Of course Stack Overflow had the remedy when I became tired of renaming my auto generated fields and removing "this.". So thanks for that kspearrin and Maciek! :)

Are the line numbers missing in the call stack of your logged exceptions?

Sometimes when being on a bug hunt it can be a great help to read the call stack of a logged exception and to be able to see which line the exception was thrown from.

So, if your logs lacks line numbers like this one below, you don't get that extra help...

System.NullReferenceException: Object reference not set to an instance of an object.
   at LineNumberDemo.Program.ThirdMethod(Int32 value)
   at LineNumberDemo.Program.SecondMethod(Int32 value)
   at LineNumberDemo.Program.FirstMethod(Int32 value)
   at LineNumberDemo.Program.Main(String[] args)

To fix that you have to change the Debugging information setting in the project's build settings. 

- Open the Properties for your project. 

- Click Build > Advanced and change "Debugging information" from "None" to "Pdb-only".

The pdb (Program database) files contains the infomation needed to map an instruction in your program to the original line in the source file. After changing that setting the log now looks like this:

System.NullReferenceException: Object reference not set to an instance of an object.

   at LineNumberDemo.Program.ThirdMethod(Int32 value) in C:\Code\LineNumberDemo\LineNumberDemo\Program.cs:line 42

   at LineNumberDemo.Program.SecondMethod(Int32 value) in C:\Code\LineNumberDemo\LineNumberDemo\Program.cs:line 35

   at LineNumberDemo.Program.FirstMethod(Int32 value) in C:\Code\LineNumberDemo\LineNumberDemo\Program.cs:line 29

   at LineNumberDemo.Program.Main(String[] args) in C:\Code\LineNumberDemo\LineNumberDemo\Program.cs:line 16

In Visual Studio 2017, "Pdb-only" is the default setting for the Release configuration, but I'm not sure it always has been, because I've seen lots of projects that did not include the pdb-files. They make the release bigger, but as long as that isn't a problem, I don't see any reason to not include them.

Good bug hunting!