8 Visual Studio debugging tips – debug like a boss

There are so many useful debugging features built into Visual Studio that aren’t well known. Here are a few my favorites including some recent finds in VS 2013.

1. Breakpoint inside a lambda

If you click the left gutter to set breakpoints you could be easily mislead into thinking breakpoints happen at line level.

You can actually insert a breakpoint inside parts of the line such as inside a lambda in your LINQ expression. Just right-click the part of the code and choose Breakpoint > Insert breakpoint from the context menu.

2. Usable output window

The output window is useful for debugging where breakpoints would be too invasive or interrupt flow but it’s pretty noisy.

Just right click in the output window (make sure output is set to debug) and turn off the Module Load, Module Unload, Process Exit and Thread Exit to leave you with stuff you actually care about. Now Debug.WriteLine to your heart’s content.

Visual Studio output window filtering options

You can also press Ctrl-S in the output window to save the contents.

3. Attach debugger to client and server (VS 2012)

It’s useful to have both server and client projects in a single solution so you only need one copy of Visual Studio running and don’t get lost alt-tabbing back and forth especially if they share common code such as a data model project.

One disadvantage is that the start-up project is the only one to get a debugger attached. If you encounter an exception it will show in your client not your server project.

That’s easily solved now. Right-click on the solution, choose properties and choose Multiple startup projects then select the Start action for the projects you need to attach to.

Visual Studio Solution properties dialog

4. Create a repro project template

If you’re responsible for a SDK or API create a simple application that uses your stuff in a small self-contained way. Then use File > Export template… to save it.

Now you can create a new project from your template whenever you need it with a few clicks. Even better make it available to users and testers so they can send you minimal repros.

5. Use the DebuggerDisplay attribute

By default the debugger will use ToString() for watch and auto windows which normally outputs class name. Even if you overwrote ToString it’s probably not what somebody debugging wants to see at a glance.

Add DebuggerDisplay to your class with a simple expression to evaluate properties instead. e.g.:

[DebuggerDisplay("Order {ID,nq}")
class Order {
    public string ID { get { return id; } }
}

The "nq" prevents double-quotes from being emitted. You can also use methods here too but don't do anything with subtle side-effects otherwise your observation of the subject will change its behavior and could cause weird issues.

6. Manage breakpoints

You set-up some interesting breakpoints and now you need to switch one off for as it's getting hit too much but you'll need it again in a minute. If you remove the breakpoint you'll have to come back and find it again.

Enter the much-overlooked Breakpoints window (Ctrl-Alt-B). This will show all breakpoints you have set but crucially lets you disable them without unsetting them by simply removing the check-mark. Check it again to re-enable it.

Visual Studio breakpoints window

This window also provides the ability to quickly:

  • Condition when a breakpoint should occur
  • Hit count to see how often it is hit and to only break based on that count
  • Label a breakpoint to allow toggling on and off in batches
  • When Hit to put a message in the output window instead of actually breaking

7. Break on or output the caller information (.NET 4.5/Windows 8 Store)

There isn't a global variable for the current method of the caller and getting the current stack can be a very slow operation.

One quick and simple trick is to add an extra optional string parameter to the method with the CallerMemberName attribute. e.g.

void MyFunction(string someValue, [CallerMemberName] string caller = null) {
    ...
}

Because it is an optional value you don’t need to modify any callers but you can now:

  1. Set a breakpoint condition inside DoSomething based on the caller variable
  2. Output the contents of caller to a log or output window

You can also use CallerLineNumber and CallerFilePath. Also remember that constructors, finalizers and operator overloads will display their underlying method names (.ctor, op_Equals etc).

8. See the value returned by a function (VS 2013, .NET 4.5.1/Windows 8.1 Store)

Sometimes you want to see what a function returned but you can’t easily because you didn’t store the value because it was the input to another function.

This was added in VS 2013 but is incredibly easy to miss as you have to be in the right place at the right time. The right place is the Autos window and the right time is exactly the step that returned you to where the function was called from. You won’t see this before you call the function or while in the function. It’s there for a single step and looks like this:

Visual Studio autos window

The arrow icon indicates it’s a return value and it lets you know the name of the function alongside it.

Wrap up

I also can’t stress enough how useful having logs are for troubleshooting once the software leaves your machine but that’s a much bigger discussion than this one.

Am I missing some great debugging tips? Feel free to let me know below :)

PS: Michael Parshin has some great tips on debugging too.

[)amien

5 simple steps to publishing a NuGet package

There is a fair amount of info on making and publishing NuGet packages but I couldn’t find a simplified guide for the simple case. Here it is and start by downloading nuget.exe and putting it in your path.

1. Multi-platform considerations (optional)

Supporting multiple platforms gives you a choice to make:

  1. Portable Class Library (PCL)
  2. One project with MSBuild magic
  3. Multiple projects

If you can go with PCL do it. For CSharpAnalytics we use platform-specific system info and hooks so it’s not an option – we went with multiple projects.

Multiple projects

Creating a separate .csproj for each platform and putting in the same folder means adding files isn’t too painful (show all files then include the ones you need) but you do need to take steps to make sure the build process for the projects don’t interfere with each other by separating the bin and obj paths:

  1. Set the output path in the Build tab of project properties to be unique per configuration to for the bin files, e.g. “bin\Net45\Release\”
  2. Edit the .csproj file adding a BaseIntermediateOutputPath tag for obj files, e.g. <BaseIntermediateOutputPath>obj\Net45</BaseIntermediateOutputPath>

2. Create your .nuspec definition

Now that you know which release dll files you need to include you can go ahead and create the nuspec file that tells nuget how to package your files up.

Open a PowerShell and type nuget spec to create you an XML file to edit in your text editor

Once you’ve entered your author details, a snappy description and links to your project page and license you can then add the files. Libraries will want to copy the .dlls into the lib folder with element like these:

<file src="..\bin\Net45\Release\MyLibrary.dll" target="lib\net45" />

Each platform will require a specific target and they should use platform name (e.g. net45, sl5, windows8) described in the NuSpec creating packages documentation. That page has a lot more detail on things such as content file types etc.

If you prefer a graphical UI then NuGet Package Explorer will make your life easier.

Remember to check your .nuspec file to source control (there is nothing private in it) and add it to your solution as a solution item so it doesn’t get missed.

3. Create your .nupkg package

The easiest part of the process. From PowerShell type:

nuget pack yourfile.nuspec

If all goes well it will create yourfile.nupkg.

4. Test your package

Just because your package was created doesn’t mean it works and you don’t want to publish to the world until you know it works especially given you can’t delete packages from NuGet:

  1. Create a folder to be your own private testing NuGet repository, e.g. c:\testnuget
  2. Publish to your test repository with nuget publish yourfile.nuspec -source c:\testnuget
  3. Configure Visual Studio to use your test repository by going to Tools > Library Package Manager > Package Manager Settings > Package Sources and then adding your test folder to the Available package sources test
  4. Create a new test application and then add a reference using Manage NuGet Packages to choose your new package from your test repository.
  5. Write a few lines of code to test you can actually use your package ok!

5. Publish to the world

Okay, you’re now ready to publish. If you haven’t yet signed up for an account over at Nuget.org you’ll need to do that first.

  1. Go to Your Account and copy your API key
  2. Run the PowerShell command nuget setApiKey followed by your API key, e.g. nuget setApiKey 99995594-38d2-42cd-a8b1-ddcd722bb7e7
  3. Run nuget publish yourfile.nuspec again this time without the -source option to publish to the default public repository

[)amien

A case for my MacBook Pro: Snugg wallet case review

I did it. Earlier this year I caved and purchased a MacBook Pro 15" Retina after being Mac-less for a few months despite some reservations about the lack of upgrade options.

Finally I had a lovely unibody machine. Now I needed something to prevent the beating my 17" acquired over the years – something with a bit of padding to prevent the occasional bump as my backpacks tend to be very thin.

Imagine my surprise when the people at Snugg asked if I was interested in a free case to review. I’d been considering something quite plain but my eyes lit up at their Snugg MacBook Pro 15 Wallet Case in Brown Leather.

The case arrived a few days later and you can just smell the leather. The outside is a slightly rough texture (on the brown at least) with very neat stitching while the inside is a very smooth microfiber – presumably to ensure the MacBook slides in nicely.

Front of my MacBook Pro case.

The front flap snaps down with quite a strong magnet – a worry for the older magnetic hard drive machines perhaps but not a concern for people with SSD drives. It also features a small business card holder and the back has a full-width pouch that easily fits a few documents.

The fit is great, it is indeed "snugg" without being tricky to remove. Despite providing good protection the case isn’t bulky and fits nicely into my backpack and on one occasion I’ve just carried it as-is. Hmm I wonder if you could attach a shoulder-strap…

Side view of my MacBook Pro in the case.

I’ve taken to putting the case under my laptop – the slightly thicker top angling the laptop keyboard to a more comfortable position.

Overall a very nice case – I might grab one for my iPad and my wife has made it known to me that she’d quite like one too!

[)amien

Probable C# 6.0 features illustrated

Adam Ralph has a list of the probable C# 6.0 features Mads Torgersen from the C# design team covered at new Developers Conference() NDC 2013 in London.

I thought it would be fun to show some before and after syntax for comparison and in doing so ended up with a few thoughts and questions.

1. Primary Constructors

Shorter way to write a constructor that automatically assigns to private instance variables.

Before

public class Point {
    private int x, y;

    public Point(int x, int y)
        this.x = x;
        this.y = y;
    }
}

After

public class Point(int x, int y) {
    private int x, y;
}

Thoughts

  • Do you need to independently define x and y?
  • Can you still write a body?
  • How would you make the default private?

This solution feels too constrained, would have preferred something like:

public Point(set int x, set int y)

That set the property and optionally created a private one if it didn’t. Would allow bodies, use on multiple constructors etc.

2. Readonly auto properties

Readonly properties require less syntax.

Before

private readonly int x;
public int X { get { return x; } }

After

public int X { get; } = x;  

Thoughts

  • Love this.
  • Very useful for immutable classes.

3. Static type using statements;

Imports all the public static methods of a type into the current namespace.

Before

public double A { get { return Math.Sqrt(Math.Round(5.142)); } }

After

using System.Math;
...
public double A { get { return Sqrt(Round(5.142)); } }

Thoughts

  • Not something I’ve run into often but no doubt very useful for Math-heavy classes.
  • Could be useful for Enumerable LINQ-heavy classes if it works with static extension methods.

4. Property Expressions

Allows you to define a property using a shorthand syntax.

Before

public double Distance {
    get { return Math.Sqrt((X * X) + (Y * Y)); }
}

After

public double Distance => Math.Sqrt((X * X) + (Y * Y));

Thoughts

  • Small but useful syntax reduction.
  • Has nothing to do with System.Linq.Expression despite the name.

5. Method Expressions

Allows you to define a method using a shorthand syntax.

Before

public Point Move(int dx, int dy) {
    return new Point(X + dx1, Y + dy1);
}

After

public Point Move(int dx, int dy) => new Point(X + dx, Y + dy);

Thoughts

Same as Property Expressions.

6. Params for enumerables

No longer need to define your params methods as an array and force early evaluation of the arguments.

Before

Do(someEnum.ToArray());
...
public void Do(params int[] values) { ... }

After

Do(someEnum);
public void Do(params IEnumerable<Point> points) { ... }

Thoughts

  • Can have params methods for IEnumerable and array side-by-side? Probably not.
  • Is evaluation deferred until evaluated if you pass a single IEnumerable instead of a params?

7. Monadic null checking

Removes the need to check for nulls before accessing properties or methods. Known as the Safe Navigation Operator in Groovy).

Before

if (points != null) {
    var next = points.FirstOrDefault();
    if (next != null && next.X != null) return next.X;
}   
return -1;

After

var bestValue = points?.FirstOrDefault()?.X ?? -1;

Thoughts

Love it. Will reduce noise in code and hopefully reduce null reference errors everywhere!

8. Constructor type parameter inference

Removes the need to create static factory methods to infer generic types. This is helpful with Tuples etc.

Before

var x = MyClass.Create(1, "X");
...
public MyClass<T1, T2> Create<T1, T2>(T1 a, T2 b) {
    return new MyClass<T1, T2>(a, b);
}

After

var x = new MyClass(1, "X");

Thoughts

  • Another great addition.
  • Does it understand list and collection initializers to automatically determine the generic types too?

9. Inline declarations for out params

Lets you declare the out variables inline with the call.

Before

int x;
int.TryParse("123", out x);

After

int.TryParse("123", out int x);

Thoughts

  • Not a particularly large syntax reduction.
  • Shorter code for Try methods and DirectX.

Wrapping up

Hopefully there are a few more gems to come that would help reduce noise. Would especially like to see syntax that wired up an interface to an internal instance variable where not specifically overridden to aid in encapsulation, e.g.

public MyClass : IList => myList {
  private IList myList;

  public Add(object item) {
    // Do something first
    myList.Add(item);
  }
}

[)amien