About a year ago, I ran into a weird bug. After having cloned a repository from Azure DevOps, I was baffled to see that the Solution Explorer in Visual Studio was not showing any files, even though there were plenty:

This problem still annoys my colleagues to this day. What happened in every case was that there was a space in the name of the project in Azure DevOps, so cloning the repo resulted in a folder that included %20 in the name. As I’m sure you’re aware, that’s the URI-encoded version of a space.

Unfortunately, for whatever reason, Visual Studo does not like this very much. It’s not a big deal though. Simply change that %20 to an actual space, and the files suddenly show up in Solution Explorer:

This problem seems to apply only to .NET Core projects. I haven’t been able to replicate it for older .NET Framework projects.

This is another of those little things that are right there and yet many people seem to not know about them.

There’s a little handle at the top-right corner of the code window:

When you drag it down, it will split your code window into two parts:

This is very useful when you want to look at two different places within the same code file (e.g. while examining one method, check another one declared earlier in the same file).

At any time, you can drag the splitter in the middle all the way to the top to go back to single view.

Here’s a scenario just about everyone has run into: you had this try/catch block:

try
{
    // ...
}
catch (Exception)
{
    // ...
}

You didn’t need the exception variable, for whatever reason. Although you’d typically leave it there in case you needed to dig deeper into the exception, you got tired of Visual Studio nagging about the unused variable, and removed it.

And then, it happened: an exception occurred, and you actually needed the detail.

As it turns out, there’s a way you can see the exception detail without adding the exception variable back and reproducing the issue a second time. There’s a special $exception variable that you can use in the Locals, Watches, or Immediate windows:

An additional benefit is that since $exception is local to the scope in which your instruction pointer is, you can check the exception detail even if you’re looking at code elsewhere in the project, without having to go back and find the exact place where your exception was thrown.

A big thanks goes to this Stack Overflow answer for this handy little tip.