Get the Path to Your File in Visual Studio

One of the best things about Solution Explorer is that I can right-click on a Project, pick "Open Folder in File Explorer" and, a second later, I'm in Windows Explorer, able to work with the files that make up the project. This also works with Solutions or, really, any folder displayed in Solution Explorer (for example, if you have Show All Files turned on, you can use this with the bin folder or obj folders).

Often, however, I'm not focused on the Project (or Solution) as a whole: I'm interested in one specific file -- usually, the one that I have open in my editor window. When that's the case, I can just right-click on the file's editor tab and select "Open Containing Folder." This not only opens the appropriate folder in Windows Explorer, it also selects and highlights the file I'm interested in.

Posted by Peter Vogel on 04/21/2016 at 12:22 PM0 comments

Organizing Visual Studio Project Templates

Visual Studio has lots of templates but you probably use only a few of them. Why not create your own area with all (and only) the templates you actually use?

It’s easy to do: First, shut down Visual Studio. Then, open Windows Explorer and surf to the folder that holds your templates. This folder can move around a lot. For Visual Studio 2015 Community Edition on my computer, it’s at C:\Users\<username>\Documents\Visual Studio 2015\Templates\ProjectTemplates. For Visual Studio 2012 and earlier, I’d recommend looking in the area of C:\Program Files (x86)\Microsoft Visual Studio<version>Common7\IDE. If you can’t find the folder, probably the simplest solution is just to do a search for the ProjectTemplates folder from Windows Explorer.

Once you’ve found the ProjectTemplates folder, add your own subfolder within it and copy the templates you want from the other subfolders into your new folder.

After you’re done with that, make sure your computer is plugged in, your battery charged, and open the Visual Studio command prompt. In the command prompt type: /installvstemplates

One caveat: For Visual Studio 2015, I also had to navigate down to Common7/IDE before entering the command. Now press Enter and wait.

Microsoft stresses that it’s critical that you let this command run to completion, which is why it’s a good idea to make sure you won’t run out of power part way through. When the command finishes (when the prompt reappears in the command window), open Visual Studio and go to your project list. You should find your new area with the templates you selected in the project templates list.

Posted by Peter Vogel on 04/07/2016 at 12:10 PM0 comments

Step Out of Debugging To, Well, Wherever You Want

When you're debugging, you probably know that you can use the Debug | Step Out menu choice to exit a method without having to step through all the code in the method. But, if you want to step out and back to some higher-level method, you can do that also by using the Call Stack.

If you're not displaying the Call Stack window when stopped at your breakpoint, go to the Debug menu and select Windows | Call Stack. When the window appears, right click on the method where you want to stop again and select "Run to cursor" to continue executing until you get back to that method.

The first time you use this technique is a bit of a pain because you probably don't have the Call Stack window open. After you've used it the first time, however, the window will be right there waiting for you the next time you need it.

Posted by Peter Vogel on 04/01/2016 at 11:58 AM0 comments

Supporting LINQ Queries Calling Your Methods

You have a method like this that returns a collection of premium Customer objects:

Public Function GetPremiumCustomers() As List(of Customer)
  Dim db As New dbContextObject
  Return From c In db.Customers
         Where c.IsPremium = True
         Select c
End Function

The problem is that other developers will want to use your method to further refine this query:

res = (From c in GetPremiumCustomers()
       Where c.City = "Regina"
       Select c).ToList()

If you're not careful the GetPremiumCustomers will retrieve every premium customer when the developer using your method only wants some of the premium customers (the ones in Regina). Retrieving more data than you'll ever want is a sure way to slow down your application. Wouldn't it be great if the LINQ query inside your method could be combined with the LINQ query using your method when the SQL statement is generated?

You can give .NET the opportunity to do exactly that -- to collapse both queries into a single SQL statement that retrieves only the premium customers from Regina -- if you just declare your GetPremiumCustomers method as returning the IQueryable interface. All you need to do is write your function's signature:

Public Function GetPremiumCustomers() As IQueryable(of Customer)
  Return From c In db.Customers
         Where c.IsPremium = True
         Select c

to return a result of IQueryable.

Posted by Peter Vogel on 03/16/2016 at 12:07 PM0 comments

The Special Case Pattern

You have a GetCustomerById method in a factory object inside a repository that, when passed a CustomerId, returns a Customer object. Except, of course, sometimes there isn't a matching Customer object to return. What's the best way to handle this?

You have three options:

  1. Raise an exception.
  2. Return Nothing/null
  3. Return a "special object"

Raising an exception has performance implications because everything stops for tea when .NET processes an exception. Really, you should only raise an exception if you intend to stop processing … and that's not a decision that should be made by some method in some middle-tier object. Stopping the application is a decision that should be made by the application itself.

The second option isn't a bad one … except that quite a lot of code doesn't deal well with null references. By returning null/Nothing you're forcing the developer calling your method to wrap it in a Try…Catch block (there's those exceptions again) or test for null. And a null reference doesn't tell the developer much about what went wrong.

Your third option is really your best choice and it even has a name: The Special Case pattern. The only wrinkle is that your special object has to be compatible with the datatype that your method is returning (Customer, in this case). Your special object will, therefore, need to be some class that shares an interface with the objects that your method normally returns.

If, for example, your method returns a Customer object then your special object will need to be something that inherits from Customer -- a CustomerNotFound class, for example. The CustomerNotFound object should have all of its properties set to their default values.

Now code that calls your method can use the datatype of the special object:

Dim cust As Customer
cust = CustomerFactory.GetCustomerById("A123")
If TypeOf cust Is CustomerNotFound Then

to see what kind of error occurred.

Posted by Peter Vogel on 03/04/2016 at 2:53 PM0 comments

Making Your Code More Loosely Coupled

As programmers, we often talk about how it's better for components of an application to be isolated from each other. We recognize that, with our present programming tools, some level of coupling is unavoidable. We take it for granted, for example, that we have to use "signature coupling": To call a method we must know the method's name, the format of its parameter list and the data type of its return value.

But we also recognize that when we go beyond that level of coupling we start to create problems for ourselves. The primary problem is that, as components are more tightly coupled, changes in one component require changes in other components … and changes in those "other components" then require changes to still more components.

Where, I think, many developers don't realize that they've made their components too tightly coupled is in what's called "control coupling." Control coupling occurs when you pass a parameter to a method that controls the way the method behaves. The clue here is that inside a method you have an If statement (or some other conditional) that tests a parameter passed to the method and, based on that test, has the method do something different (other than, perhaps, throwing an exception because bad data was passed in the parameter).

Effectively, with control coupling, the code that calls a method is messing with the internal processing of that method. With this level of coupling any changes to how those control parameters are used (in either the method being called or in the calling code) are going to require changes to the other set of code.

The first step in reducing this level of coupling is to recognize that when you write code like this you're probably violating the separation of concerns principle: You have a method that does two things rather than doing one thing well. Your If statement is selecting between the two different things your method is doing. You're probably going to be better off to write two methods, each of which handles one piece of functionality.

There are two benefits here. First, all the versions of your method will now be much simpler. Simply eliminating an If statement cuts your method's complexity in half (after all, now there's only one path through the method to test). Second, when you want to change how things are done, you won't change any existing code. Instead, you'll write a new method that does the right thing and have your application call that method. By doing this, you avoid violating Vogel's first law of programming: Don't screw with working code!

If you feel that's going to make calling the right method hard to do, remember that you have options for simplifying that. Overloading will let you create multiple versions of a single method, each version of which is dedicated to handling a specific parameter list.

Moving code to classes derived from the same base class will let you hide different versions of the code behind the same signature (for example, the CreditCheck method does something different in PremiumCustomer than it does in DeadbeatCustomer). Any common code shared between the two versions can be put in the base class. You don't even need a base class: The Strategy and Role design patterns also allow you to put different implementations behind the same signature, as will effective use of interfaces.

If you value loose coupling, reducing control coupling might be your next step.

Posted by Peter Vogel on 02/26/2016 at 12:22 PM0 comments

Add Custom Data to Exceptions

When it comes to debugging problems with your code, a good Exception object is your most valuable tool. I've talked before about how why returning information about an exception using the InnerException object will let you find out what the real problem is without giving away secrets about your application.

I've also discussed how to ensure that your server-side errors aren't masked by the generic 500 "something's gone wrong" HTTP error. I've even gone as far as to suggest that it might be useful to create your own custom exception object.

Some people might conclude that my programs must throw a lot of errors but that's not true. My concern is simple: Knowing precisely what went wrong when your program blows up helps you figure out what the problem is. Furthermore, knowing what data exposed the problem is often critical to solving the problem. To help you out with that, the Exception object provides a dictionary where you can tuck away data about an error that programs processing the error can use -- it's the Exception object's Data property.

The following code adds an item to an Exception object's Data collection with a key of CustomerId and sets that key to a value. The code then throws an Exception of its own, tucking the original exception (with its additional information) into the InnerException property:

   ...code that might throw an exception...
Catch ex As Exception
   ex.Data.Add("CustomerId", custId)
   Throw New Exception("Failure in processing Customer", ex)
End Try

Alternatively, you can create your own Exception object and add to its Data collection:

   ...code that might throw an exception...
Catch ex As Exception
   Dim myEx As New Exception("Failure in processing Customer", ex)
   myEx.Data.Add("PersonId", pers.FirstName)
   Throw myEx
End Try

The code that processes an Exception doesn't have to know precisely what's in the Data collection in order to report on it. Instead, you can just write out everything in the Data collection using code like this:

For Each key In ex.Data.Keys
  Debug.Print(key & ": " & ex.Data(key))

There are two things to avoid here. First, make sure that retrieving the information you're going to put in the Data collection won't itself trigger an exception (don't try to set a key to the property of a potentially null reference, for example). Second, don't add to the collection of any Exception object that you haven't just created because you might overwrite a Data value that was set elsewhere.

Posted by Peter Vogel on 02/23/2016 at 12:11 PM0 comments

Skip Back to an Earlier Change in Visual Studio

One of my favorite features in Visual Studio is Ctrl+- (hold down the Control key and press the minus key). Every time I press Ctrl+-, I skip back to the previous place I rested my cursor. I use this feature a lot when, after navigating through my code to investigate something, I want to get back to my start position so that I can make my actual change.

The only problem with Ctrl+- is that it keeps track of almost every place I stopped -- getting back to the point where I want to make my change can require a lot of key presses.

There is a faster way: The navigation buttons at the left-hand end of the Visual Studio toolbar. In more recent versions of Visual Studio, these are two blue circles with right and left arrows on your toolbar; in earlier versions these are square buttons (still on the toolbar) with a page icon, plus right and left arrows. If you click the little down arrow beside these icons you'll get a list of all the places you visited recently: Just click on the one you want to go back to.

Posted by Peter Vogel on 02/16/2016 at 10:12 AM0 comments

Open an ASP.NET MVC Dialog Box with Backbone

I recently wrote a column on how to open a dialog box in an ASP.NET MVC application. In that column, I had the HTML for the dialog box dynamically generated at runtime from a Partial View and retrieved it by issuing an AJAX call from JavaScript running in the browser that called a method in my ASP.NET MVC Controller. To actually display the dialog I used the jQueryUI dialog add-in.

A reader sensibly asked: Why not use the Backbone JavaScript library rather than jQueryUI for that final step? After all, as the reader pointed out, Backbone comes with ASP.NET MVC. Other than habit (I've been using jQueryUI for a very long time) I didn't have a good answer to that question.

So this tip is what you need to do differently if you want to use Backbone to open your dynamically generated dialog and, so, save yourself adding the jQuery library to your project. (One note: to make sense of this tip you might need to read that original column.)

Fortunately, for me, there are only two things to change in moving from jQueryUI to Backbone. First, on the server, I change the HTML I put in the Partial View that defines the dialog (or, as Backbone refers to it, the "modal"). While jQueryUI will display almost any old HTML as a dialog, Backbone prefers a specific structure that enables you, for example, to define the modal's header, body and footer.

Listing 1 show some typical HTML that I could put in a Partial View to generate a Backbone modal that has a title block, a body containing a textbox, and a footer with a button that closes the dialog. That HTML leverages both some Backbone attributes (role, data-dismiss) and some Backbone styles (modal fade, modal-dialog and so on).

Listing 1: HTML for a Backbone Modal

<div id="divModal" class="modal fade" role="dialog">
  <div class="modal-dialog">
    <div class="modal-content">
      <div class="modal-header">
        <h2 class="modal-title">Customer Name</h2>
      <div class="modal-body">
        <input type="text" id="CustomerNameNew" value="@Model.FirstName" />
      <div class="modal-footer">
        <input type="button" value="Exit" data-dismiss="modal"/> 

Second, I need to change the JavaScript that actually displays the modal. If the Backbone modal's HTML is more complicated than the equivalent jQueryUI HTML, the Backbone JavaScript is much simpler (much of what I did in code with jQueryUI is handled through the HTML that defines the Backbone modal). With Backbone, I just call Backbone's modal function, referencing the div element that defines the modal.

Here's the JavaScript code to call my Controller method on the server (passing some data from the page), insert the resulting HTML retrieved from the View into a div element on the page (called divDialog here) and then display the modal:

function ShowModal() {
                { id: $("#CustomerId").val() },
                function (dialogHTML) {

By the way, if you don't need to generate your modal's HTML dynamically at runtime (for example, if the dialog is nothing but static HTML) you can add Backbone's data-toggle and data-target attributes to an element so that, when that element is clicked, your modal will display. This input element will display a dialog in the same page:

<input type="button" id="showModal" value="Get Customer Name" data-toggle="modal" 

without requiring any JavaScript!

Posted by Peter Vogel on 02/05/2016 at 12:56 PM0 comments

Ensure HTML Forms Are Closed with the Using Block and BeginForm

In your Views, you can get the BeginForm helper to not only write out the open tag for your HTML form, but to write out your form's end tag. The trick is to call BeginForm as part of a Using block. The code looks like this, in Visual Basic:

@Using Html.BeginForm(...parms...)
  @Html.EditorFor(... of form...
End Using

This C# code does the same thing:

@using (Html.BeginForm(...parms...))
  @Html.EditorFor(... of form...

At the end of the Using block, the compiler will automatically call the Dispose method of the class the BeginForm uses. That Dispose method will politely add the end form tag to your page, so you'll end up with something like this:

<form action=" of the attributes...>
  <input type="text"... of form...

As you can see, the Using block also creates a structure in your View that you can slip all of your form elements inside.

Posted by Peter Vogel on 01/28/2016 at 10:56 AM0 comments

Hiding Methods from IntelliSense

Believe it or not, there are times when you have a member in your class that you don't want to appear in the class's IntelliSense lists.

In a column earlier this month I talked about how to have your class work with the .NET Framework support for formatting strings (things like "{0:G}," for example). By the time I had finished implementing this feature, my sample class had a method that no developer would ever call -- the method would only be called by .NET Framework components.

Because my method will never be called by a developer, it doesn't make a lot of sense to have that method cluttering up the class's IntelliSense list. To stop that method from appearing in the class's IntelliSense list, I could decorate the method with the EditorBrowsable attribute, passing the enumerated value EditorBrowsableState.Never. Here's the method from that column with the attribute applied to it:

Public Function ToString1(format As String, formatProvider As IFormatProvider) As...

The trouble is, other than suppressing this ToString method, I literally cannot think of any other case when I'd want to use this attribute (after all, if I wanted a developer to stop using the method, I'd decorate it with the Obsolete attribute).

I suppose you could use the two attributes together: one to hide the method so a developer won't know about it while keeping the method in the class so old code would run; the other attribute to generate compile time warnings about how existing code should stop using the method. But that sure seems like a lot of work to invest in something you don't want people to use.

Posted by Peter Vogel on 01/21/2016 at 10:34 AM0 comments

Combining LINQ Queries (or, When to Call ToList)

LINQ with Entity Framework has become so common that, when I'm looking at a client's code I'm finding some pretty scary-looking LINQ queries running against Entity Framework. Since I'm a big fan of Really Obvious Code (ROC) -- ROC Rocks! -- I hate having to parse out these queries to try and figure out what the query is doing (and what's wrong with it).

You might be tempted to write a comment to explain the query (but I don't like that, either).

The right answer is to break down your complicated query into several smaller, easily readable queries that build on each other. While this isn't a particularly complicated example, these two queries find all of the people whose last name is "Vogel" and work for PH&VIS:

Dim persVogel = From p In db.People
                Where p.LastName = "Vogel"
                Select p

Dim persVogelPHVIS = From pp In persVogel
                     Where pp.Company.Name = "PHVIS"
                     Select pp 

While this looks inefficient, it's not. It's important to remember that a LINQ query doesn't result in any data retrieval: At this point in my sample code, my persVogel and persVogelPHVIS variables are just holding LINQ queries; the variables aren't holding the results of those LINQ queries (at least, not holding the results yet).

It isn't until you start working with the individual objects that Entity Framework will finally issue a SQL statement against your database. When that SQL query is finally issued, Entity Framework will take care of collapsing those two LINQ queries into one SQL statement for you.

One way to trigger that retrieval is to use the ToList method. If my LINQ queries were in a method, then I might finish the method with code like this:

Return persVogelPHVIS.ToList()

At this point, when the ToList method executes, Entity Framework will finally retrieve the data and create a collection of objects from that data.

Besides, those collections of objects are more generally useful than the LINQ queries. I've had numerous clients call me up to ask why they're getting messages like "Unable to cast object of type..." when passing a LINQ query to some function. The usual solution is to add a call to ToList to force Entity Framework to retrieve the data.

Posted by Peter Vogel on 01/19/2016 at 10:51 AM0 comments

Upcoming Events

.NET Insight

Sign up for our newsletter.

I agree to this site's Privacy Policy.