Bugs Are Features Too

It’s surprising how many bugs on Microsoft Connect are closed as Won’t Fix with a reason that fixing the bug would be a breaking change.

The logic is that someone could be dependant on the errant behaviour and thus changing it would cause their code to break.

Here’s some samples.

TypeConverter.IsValid(Object).  This method is described as “Returns whether the given value is valid for this type”.  But, this results in true:

            TypeConverter typeConverter = TypeDescriptor.GetConverter(typeof(int));


Based on the description of IsValid that this is what was intended: 

            Debug.Assert(false == typeConverter.IsValid(“ten”), “TypeConverter.IsValid return true when it shouldn’t have”);

            Debug.Assert(true == typeConverter.IsValid(“10”), “TypeConverter.IsValid return false when it shouldn’t have”);

Ergo, the argument is there must be some code out there that relies on the fact that IsValid returns true for invalid values.  The best I could come up with was:

            TypeConverter typeConverter = TypeDescriptor.GetConverter(typeof(int));



                MessageBox.Show(“value cannot be converted to integer”);





                Int32 value = (Int32)typeConverter.ConvertTo(“ten”, typeof(Int32));


            catch (FormatException)


                MessageBox.Show(“value cannot be converted to integer”);



If they changed TypeConverter.IsValid to return whether the given value is valid for this type then obviously it would break the above code.

That bug was logged by Daniel Cazzulino  at https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=93559

One I personally logged had to do with methods documented as “Always throws”.

There exists several methods in the framework like Convert.ToDecimal(DateTime) that do nothing but throw an exception.  The response was that the methods exist to allow easier conversion from VB6.

What scares me is that that suggests that the methods exists so that VB6 code copied to VB.NET will compile without error rather than attempting to follow a well-known axiom of getting the compiler to detect logic errors whenever possible.  Rather than providing a compile error and forcing someone to fix the problem before releasing the software, these methods allow the software to compile and it’s then the onus of the unit tests or the testers to find the runtime error.

This bug can be found at https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=94770.

DotNetKicks Image

Software Process and Reduction of Quality

Ken Schwaber had a conversation with Scott Hanselman about the concept of “done”.  He said that software developers have a habit of culling down all the generally accepted practices of software development except the writing of code.  He says that, when pushed, software developers reduce quality in an effort to produce a software product by a certain time.  This leads to a huge debt that must eventually be paid. 

These generally accepted practices include things like unit testing, refactoring, design, documentation, etc.  In the case of producing an API or and SDK, I believe these practices includes community involvement.  When a team developing an SDK, API, or IDE “goes dark”, they’re not doing their job properly–they’re ignoring the fundamental reason for their work: the customer.  This is a huge problem in our industry because software developers are effectively trained that schedules only include writing code and meetings.

I agree with Ken and would say that part of an Agile process includes a significant amount of time to communicate with customers need be scheduled.

Even if not professing to using an Agile methodology, if unit tests, integration tests, refactoring, and research don’t take up a significant amount of the software development schedule or there’s no scheduling of a significant amount of time to communicate with customers; the team is inept.  In this day and age, I would hazard to say its downright felonious and fraudulent.

DotNetKicks Image

Becoming a Visual Studio Jedi Part 1

Becoming a Visual Studio 2008 (and often Visual Studio 2005) Jedi

In much the same grain as James’ Resharper Jedi posts, I’m beginning a series of posts on becoming a Visual Studio Jedi.  It involves getting the most out of Visual Studio off-the-shelf, doing things as quickly as possible and with as little friction as possible.  I think it’s useful for all users; but especially useful for those who are in situations where they can’t install refactoring tools like Refactor Pro! or Resharper.

First, familiarize yourself with Sara’s Visual Studio Tips blog; then subscribe to her blog.

I’ll attempt to provide detail at a less granular level than Sara’s blog (i.e. using a series of commands to perform a specific task); but I may overlap here and there

Take advantage of Auto-Hide
Like Jimmy Bogard and Jeffery Palermo, I have my Visual Studio UI very lean. 99% of the time, I’m working in code.  The Solution Explorer (SE), Properties, Output, etc are auto-hide panes.  When I need to use them I hover the mouse over the tab to make them visible, do what I need to do with them, then get back to the code.  The Code Editor is the only window that isn’t auto-hide or floating.

Navigate find results via keyboard
Whenever anything is displayed in a find results window, you can iterate each item in the list via a keystroke.  The default C# keyboard map had F8 and Shift+F8 as the shortcuts for next and previous.

For example:

  1. Press Ctrl+Shift+F to bring up the Find in Files form.
  2. Enter “TODO\:.*refactor” in the “Find what” text box.
  3. Ensure Match case, Match whole word are unchecked.
  4. Ensure Use is checked and has Regular expressions selected.
  5. Press Alt+F to search.

A Find Results window is displayed that shows the results of the search.

  • F8 goes to the first result.
  • Pressing F8 again goes to the next.
  • Pressing Shift+F8 goes to the previous result.

See also:

F8 and Shift+F8 work for most lists like Find Results 1, Find Results 2, Error List, Output:Build, etc.

File name extensions when adding classes
Do you find your self selecting text in the file name when you use the Add Class wizard?  Or, do you always type “.cs” at the end of your file name?  You may be happy to know you don’t have to do that.  Simply invoke the Add Class wizard and type the name of the class.  The wizard adds the missing .cs for you.  For example:
Press Alt+P, C
Enter “MyNewClass”
Press Enter
A file MyNewClass.cs is added to your project and it contains class named “MyNewClass”.

Consider a Custom toolbar

There’s generally only handful of toolbar buttons that you might need, especially if you’re a keyboard user like me.  There’s some things that simply don’t have a default keyboard mapping.  Another good reason for having a custom toolbar item with only the buttons you use is if you often change the size of your Visual Studio window.  The default layout has two or more toolbars (depending on the edition and any add-ins you have installed).  You can carefully position those toolbars so they may take up one or two lines; but when you then shrink the size of your window the get wrapped and they won’t restore if you expand the size of your window.  Having a single toolbar means this wrapping of toolbars can never happen.

Export Settings

Once you get your UI the way you want it, you can actually save the layout. 

  1. Click on Tools\Import and Export Settings.
  2. Select Export selected environment settings.

This is really handy if you get into low-resource situations (like the application you’re developing or its framework uses up too many GDI handles and Visual Studio can’t allocate a handle to display a toolbar or a frame.  When this happens Visual Studio actually turns off those GUI elements; when you close and restart those panes/frames are no longer displayed by default.)

DotNetKicks Image