Developer Tip: Orient Your Monitor Vertically!

On my development machine, I have an external monitor physically set up in vertical / portrait orientation, instead of the “default” horizontal / landscape orientation.  My IDE (code editor) window always resides on that monitor.

Instead of writing 1000 words to explain why this works great, I’ll let a pair of pictures do most of the explaining for me.

Here’s a Visual Studio window (with the code for my open-source “Schneider’s Eleven” minimalist skin for Windows Media Player) open on my horizontal-orientation monitor at 1920x1080 resolution:

Look at all that wasted whitespace on the right half of the main code pane!  (This code was admittedly developed using fairly short line lengths, but the same wasted space effect probably still applies to at least some extent in the majority of projects out there.)

Now, here’s the exact same Visual Studio window moved over to my vertical-orientation 1200x1920 monitor:

Much less wasted whitespace!  And almost 100 lines of code are visible on the screen at the same time, making it much easier to visually scan a large chunk of source code without having to scroll around.

Having developed code this way in both Windows and Mac OS environments, I’d never go back!  Rotating a particular monitor 90 degrees is an easy configuration change in the OS display properties (in Windows, Mac OS, and evidently in Linux as well), so if your physical display stand supports it, I’d encourage giving it a try and seeing how it works for you!

Fix: “The default DbConfiguration instance was used by the Entity Framework before the '...' type was discovered” in LINQPad

For a while now, I’ve been using the excellent LINQPad to quickly run .Net Entity Framework queries using the actual object model and database mappings from one of my projects, via a DbContext connection pointed to my project’s compiled .dll file and web.config file set up in LINQPad.

Recently, after this having been working fine for a while, I started getting an error when trying to execute any queries using this DbContext connection in LINQPad:

The default DbConfiguration instance was used by the Entity Framework before the '...' type was discovered.

The "..." in that error message was actually the name of a new class that had been added to my .Net project, which derived from the DbConfiguration class.

The fix was, in my project’s web.config file, to add to the entityFramework element a codeConfigurationType attribute pointing to the new class and its package.  So, whereas before my web.config file had:

<entityFramework>
    ...
</entityFramework>

I changed it to:

<entityFramework codeConfigurationType="MyProject.MyPackage.MyCustomDBConfiguration, MyProject.MyPackage">
    ...
</entityFramework>

(Where "MyProject", "MyPackage", and "MyCustomDBConfiguration" all obviously are replaced by the actual project, package, and class names from my actual project.)

With that change in place, I was able to successfully execute queries using my project’s EF model once again.

Update 2016-06-06: A second possible cause of this same issue is if the path to your application config file (or web.config file) in LinqPad's Connection Properties dialog is incorrect.

I had this issue occur just now after moving my project to a new location on disk. I'd corrected the "Path to Custom Assembly" value in the Connection Properties dialog, but I initially neglected to make the corresponding filesystem path change to the the "Path to application config" value.

VSFileNav: Recommended Visual Studio extension for jump-to-filename navigation

Having used Visual Studio 2013 and 2015 as my primary coding IDE for the past 18 months or so, I haven’t been terribly happy with Visual Studio’s out-of-the-box support for the task of using the keyboard to open a file with a particular name (in a large solution).

As detailed in this StackOverflow question, there are a few options, none of which work well for me:

Ctrl+[comma], filename, Enter –This is frequently very sluggish on my (modern) PC, with a delay of 5-10 seconds between the search field appearing, and Visual Studio recovering from being unresponsive and actually allowing typing in the field. Worse, occasionally after typing the Ctrl+[comma] hotkey, the search term that I started typing while the application was still unresponsive (but after the search field appeared), the text I entered gets inserted into the active source code document instead of in the search field!

Ctrl+[semicolon], filename, Enter, Enter – Aside from the drawback of having to hit Enter twice, this leaves the Solution Explorer window in a state of showing only the matches for the entered search term.  To clear the search, either using the mouse or hitting Ctrl+[semicolon], Esc, Esc is needed – obviously not ideal.

Ctrl+Alt+a, of, filename – The Ctrl+Alt+a keyboard shortcut to open the Command Window doesn’t work in my Visual Studio, for whatever reason, even though that shortcut is listed in the Edit menu.  Additionally, the autocomplete in the Command Window frequently messes up my search term. For example, if I’m trying to search for a file named “property.aspx” in my solution, but my solution also has a file named “property-format.aspx”, as soon as I type “property.”, the autocomplete for some reason assumes I want “property-format” and replaces my typed search term with that.  So, no good.

Since none of the out-of-the-box solutions work for me, I resorted to trying a Visual Studio extension that provides this functionality, VSFileNav.

VSFileNav is a Visual Studio extension that binds a customizable hotkey – I’m using Ctrl+[tilde] – to open a custom File Navigation dialog allowing quick search and open of all files in the current solution.  Some reasons that VSFileNav is awesome enough that I felt compelled to blog about it:

• It’s lightning fast. Opening the File Navigation dialog, typing in the dialog to filter filenames in the solution, seeing search results update in real-time as the search term is being typed, and jumping to the selected file upon a press of the Enter key all happen effectively instantly.
• It supports Pascal-case filename search.  Typing “MCC” into the search field matches “MyCustomClass.cs” as a search result, for example.
• It just works. I didn’t have to fight with any bugs or configuration settings (beyond setting my preferred hotkey) to make the extension work; I just installed, and it worked great immediately.

VSFileNav, or something like it, really ought to be out-of-the-box functionality in Visual Studio.  But since it isn’t, if you’re a developer using Visual Studio, do yourself a favor and start using VSFileNav.

New command-line utility: crel - Clipboard Remove Empty Lines

After repeatedly being frustrated by a situation where an extra blank line was inserted between every other line when copying data from a particular program to the clipboard, I decided to write my own workaround.  “crel” (“Clipboard Remove Empty Lines”) is a simple command-line utility for Windows that removes any empty/blank lines from the text data currently on the clipboard (if there is any).

Now (after putting crel.exe in a folder on my PATH), when I copy text data to the clipboard where I know spurious empty lines are present, I can type Windows key, crel, Enter, and they’re gone.

If this is something that would be useful to you, you can get it here: crel.exe v1.0.0 (4k)

crel is also available from my Windows Utilities page.

System.Data.Entity.Core.EntityCommandExecutionException

Problem: A particular LINQ-to-SQL query selecting fields from a SQL Server view in a C# program, which ran fine in my local dev environment, produced an exception when run in the staging environment:

Exception Message: An error occurred while executing the command definition. See the inner exception for details. 

Exception Trace: System.Data.Entity.Core.EntityCommandExecutionException 
at System.Data.Entity.Core.EntityClient.Internal.EntityCommandDefinition.ExecuteStoreCommands(EntityCommand entityCommand, CommandBehavior behavior) 
at System.Data.Entity.Core.Objects.Internal.ObjectQueryExecutionPlan.Execute[TResultType](ObjectContext context, ObjectParameterCollection parameterValues) 
at System.Data.Entity.Core.Objects.ObjectContext.ExecuteInTransaction[T](Func`1 func, IDbExecutionStrategy executionStrategy, Boolean startLocalTransaction, Boolean releaseConnectionOnSuccess) 
at System.Data.Entity.Core.Objects.ObjectQuery`1.<>c__DisplayClass7.b__5() 
at System.Data.Entity.SqlServer.DefaultSqlExecutionStrategy.Execute[TResult](Func`1 operation) 
at System.Data.Entity.Core.Objects.ObjectQuery`1.GetResults(Nullable`1 forMergeOption) 
at System.Data.Entity.Core.Objects.ObjectQuery`1..GetEnumerator>b__0() 
at System.Data.Entity.Internal.LazyEnumerator`1.MoveNext() 
at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection) 
at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source) 
at [My code ...] 

Resolution: I had neglected to deploy to the staging environment (where the query was failing) a recently-created Entity Framework migration, which added a new output field to the SQL Server view being queried.  The query was failing because it was trying to select a field which didn’t actually exist on the target view.

Upon closer examination, when I reproduced the error and inspected the inner exception (which wasn’t being automatically written to the application’s error log), it was indeed of type SqlException and had the helpful message “Invalid column name ‘[my column name]’”.

So, things to try next time I see this exception:

• Examine the inner exception (as suggested by the outer exception’s error message).
• Make sure all Entity Framework migrations have been deployed to the target environment (if EF is in use).
• Check and see whether the query is trying to select a field that doesn’t exist.