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 article is based on Visual Studio 2017 Version 15.7 Preview 2. Although it’s nice to get a glimpse of good things to come, keep in mind that it’s not production-ready yet and that things may change.
With the current version of Visual Studio 2017, which is 15.6.5, you have to have really good naming to be able to look at Test Explorer and figure out what your tests actually do:
That’s because the tests are grouped based on their outcome, i.e. whether they’ve passed, failed, or not run at all.
But that’s going to change in Visual Studio 2017, where Test Explorer groups tests based on the more logical hierarchy of project, namespace, class and method:
This is also very handy because you can run a certain group of tests (e.g. tests in a specific class, or tests in a specific namespace), directly from Test Explorer, rather than having to do this by right-clicking the test code and using the context menu (which isn’t very intuitive for newer developers).
This is a small but significant improvement towards making Test Explorer more usable. It is also yet another change that brings Visual Studio closer to ReShaper in terms of functionality.
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:
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.
It turns out that constants aren’t only problematic in ASP .NET 5.
If you have a pretty long
const string with a null character (
\0) somewhere towards the beginning, then you’ll be pretty surprised to get the following error when you try to compile:
Unexpected error writing debug information — ‘Error HRESULT E_FAIL has been returned from a call to a COM component.’
Say you have a 3,000-character string that looks something like this:
const string s = "aaaaaaaaaaaa\0aa...aaaaa";
Although this is perfectly valid, Visual Studio fails to compile it:
I created a Stack Overflow question and a Visual Studio bug report for this.
Comments on the Stack Overflow question confirmed this to be a bug in the PDB writer (Eric Lippert). It’s Visual Studio specific, and doesn’t happen when compiling from the command line (Jon Skeet). Apparently it happens if the null character is before the 2033rd index in the string (Tommy).
One workaround suggested by Tommy is to use the string literal notation, which actually works:
const string s = @"aaaaaaaaaaaa\0aa...aaaaa";
Another workaround is to simply drop the