#1,213 – Visual Studio 2015 – Unused using Statements Greyed Out

In Visual Studio 2015, the editor will grey out any using statements that are not required.  This is done at build time.  Note that you can still use the Remove Unused Usings command to remove any unused statements.  (This command has been renamed Remove Unnecessary Usings).

Below, all but the first using statement is greyed out, since the code that follows makes no use of types from any of the other namespaces.



#1,185 – Managing using Directives, part II

You can add missing using directives by using the Resolve command.  You can also clean up the current list of using directives in a file, removing the ones that are no longer needed.

You can remove unneeded using directives by clicking anywhere within a file and selecting Organize Usings | Remove Unused Usings.

In the example below, we start out with 20 using directives at the top of the file.


We then select Remove Unused Usings.


After we execute this command, we’re left with only four using directives at the top of the file.


#1,184 – Managing using Directives, part I

As you write code, Visual Studio will let you know that you’ve used an identifier that it doesn’t know by marking it with a red squiggly underline.  Below, we’ve started creating a class that derives from Shape.  But Visual Studio tells us that it doesn’t know about Shape.


The easiest way to resolve this is to try right-clicking on the unknown identifer and selecting the Resolve entry.  Visual Studio will give you a list of namespaces that it can find the identifier in.  You can then select one of these options and Visual Studio will add the relevant using directive.




Note that this will only work if the identifer is valid somewhere within the assemblies that your project has referenced.  If you have correctly spelled an identifer and the Resolve option does not appear, you will need to add a reference to the assembly where the identifier in question is defined.



#1,090 – Using Visual Studio to Verify How Floating Point Numbers Are Stored

Recall that floating point numbers are stored in memory by storing the sign bit, exponent and mantissa.

We showed that the decimal value of 7.25, stored as a 32-bit floating point value, is stored as the binary value 0x40E80000.


We can verify this in Visual Studio by assigning a float to contain the value 7.25 and then looking at that value in memory.


Notice that the bytes appear to be backwards, relative to their order as written above.  This is because Intel is a little-endian platform (bytes at “little” end of 32-bit word are stored first).

#966 – Visual Studio Code Editor Helps with Indenting

You’ll typically use a consistent indent level in your source code to assist with readability.  Visual Studio helps by automatically indenting your code as you enter it.

For example, if you enter an if statement and then press Enter to move to the next line, Visual Studio automatically indents the then portion of the if statement.


You can change the indent level by:

  • Selecting Tools | Options
  • Navigating to Text Editor | C# | Tabs
  • Changing the value in the Indent size field  (default is 4)


Note that the default is to insert a series of spaces when the Tab key is pressed.

You can easily re-format a document to match the requested indent level.  For example, assume that we start with some non-indented code:


You can indent the entire document by selecting Edit Advanced Format Document.  The document will be re-formatted using the current indent level.


#957 – Naming Files that Contain C# Code

Files that contain C# code are typically named using a .cs extension.  You can, however, include C# in a code having any extension you like.  Note that in Visual Studio, if the extension is other than .cs, you’ll need to set the Build Action to Compile.  The editor will also not use Intellisense on files having other extensions, unless you specifically change this.

A file containing C# code is most often named to represent a single class or type that it contains.  This helps in finding the source code that contains a particular class.



You can, however, store any type that you like within a particular file.



You might also store several types within the same file.



You can also split the implementation of a class across multiple files, using the partial keyword.


#914 – Using the Debugger to Break when an Exception Is Thrown

By default, if you have an exception handler defined, the debugger in Visual Studio will not break (i.e. stop) at the point where an exception is thrown.

You can, however, configure Visual Studio to break at the point when the exception is thrown.  To enable breaking when an exception is thrown, do the following:

  • From the Debug menu, select Exceptions…


  • Find the specific type of exception for which you want the debugger to break and click on the Thrown column.  You can select an entire class of exceptions, or a specific exception type.  In the example below, we select all Common Language Runtime Exceptions.


  • Click the OK button

Now, when you run in debug mode, the debugger will display a dialog at the point where an exception is thrown and give you a chance to break (stop).



If you do break, you can then examine the exception object.



#912 – Intellisense Can Show Exceptions that a Method Might Throw

In some cases, when the Intellisense function within Visual Studio shows you information about a method that you are going to call, it will also list potential exceptions that the method might throw.

In the example below, we see that the Matrix.Invert method can throw an exception of type InvalidOperationException.



It’s not the case that every single method that you might call in the Base Class Library (BCL) will provide this information.  Some methods will list the exceptions that they might throw, but many will not.

#875 – Looking at the Call Stack after Catching an Exception

After an exception is thrown, it bubbles up the call stack until a handler that can handle the exception is found.  If you set a breakpoint in an exception handler, you can then use the debugger in Visual Studio to examine the call stack, as it existed at the time that the exception was thrown.

In the example below, we’ve hit a breakpoint that we set in an exception handler.  If we examine the Exception variable passed to the handler, we see that an exception of type ArgumentException has been thrown.

Notice that we can also look at the StackTrace property in the debugger.  It contains text describing the call stack at the time that the exception was thrown.  You can click on the magnifying glass icon to see the stack trace formatted in a way that’s easier to read.

In the example, we see that Dog.Bark threw the exception.


#849 – Using the Call Stack in Visual Studio to Navigate within Your Code

When in break mode within Visual Studio, you can view the call stack in the Call Stack window.

When you bring up the Call Stack window, there will be a yellow arrow pointing to the top of the call stack, indicating the location of the next statement that will execute when you resume execution.  The Locals window will show the values of local variables within the current method.


At this point, you can double-click on another method within the call stack.  When you do, the code editor will show code for that other method and the Locals window will show local variables for the same method.  They will have the values that existed at the point that the method at the top of the call stack was called.  Notice that a yellow arrow still indicates the execution point, but a green arrow now appears, showing the current method being examined.