Tag Archives: Visual Studio

I Got Your 64 bit Upgrade Right Here Punk!

I have been warned that come mid-year, I’ll be trading in my office with a view for returning to an open-plan experience in the newly constructed Sir Samuel Griffith Building up here on the Nathan campus. Beloved view, I love you!

The view from my office

The view from my office

As you might understand, I’m a little mixed about returning to an open-plan experience. It really isn’t conducive to going and staying deep in the flow, and you’d think that after research on what facilitates flow, maybe peeps would get the message that open-plan layouts actively work against certain kinds of productivity. Then again, I was raised on the open-plan experience, and this being my first “own office” experience, there’s not much shock expected.

I’ve heard that the open-plan nature of the building falls out in the wash whilst maximising amount of natural light coming into the building, reducing its carbom footprint. So, what we’ve got here peeps, is an attempt to find a sweet-spot between an environmentally sustainable building played off against maximising people’s output. I guess only time will tell on how well these researchers can maintain their flow in the new environment. Still, I feel for those researchers, entering the world of prarie-dogging for the first time.

So, in preparation for a move to the new building, our IT team has just returned my laptop. Gone the 32-bit Windows XP operating system. Hello to a 64 bit Windows 7 upgrade. The 64-bit thing was a surprise. The consequent breakage of my development environment was not. Though, now I’ve had some time to investigate it, I’m now able to describe the particular nature of my non-surprise.

It seems that we have a 32-bit install of Microsoft Office on our 64-bit machines, thanks to some incompatibilities with other 32-bit software that is in common use on campus. My “Species Benefit Optimiser for the Murrumbidgee Wetlands” relies on Microsoft Excel to import model data through the usage of the ACE Database engine. As Excel is 32-bit, I need the 32-bit ACE library.

Though I can compile my tool to use “Any CPU” as my target platform via Visual Studio, I get this fun little runtime error unless I specify a target platform of “x86”, guaranteeing that the 32-bit ACE driver gets picked up and used for conversations with Excel:

The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine.

The ‘Microsoft.ACE.OLEDB.12.0’ provider is not registered on the local machine.

If I DO compile it against a target platform of “x86”, I get this runtime error instead:

BadImageFormatException

BadImageFormatException

Which is in many ways worse, because my most foundational support library is apparently borked, as opposed to just a rogue Microsoft library that with a little more work, could be made optional.  Lots of interesting trawling ensued.

Once again, StackExchange delivered the non-nonsense heart of the issue.  Ihe VisualStudio debugger is running 64-bit, and has a cow trying to debug a 32-bit application.  I tested this out and confirmed it for myself.  I can run my application just fine from within VisualStudio so long as it’s not with the debugger.

I’ve considered and rejected a lot of workarouds.   The winner is an approach where I coax VisualStudio to run its debugger as a 32-bit  application. They tell me I need to run a command from the VisualStudio command prompt in administrator mode.  Here’s a picture of  that happening:

Running the VisualStudio Command Prompt As Administrator

Running the VisualStudio Command Prompt As Administrator

They also warn me that the command modifies the debugger executable, meaning we’re taking an all-or-nothing approach to debugging 32-bit applications.  As I may want to get back to 64-bit applications, here’s another picture of me keeping both a 32-bit and a 64-bit backup of the exeutable, so I can toggle this hackery later:

Creating a 32-bit Debugger... carefully

Creating a 32-bit Debugger… carefully

And done.  The debugger is working again on my 32-bit application, though this degree of hackery last left me shaken, not stirrred.

Advertisements

Dragged and Dropped across AppDomain boundaries.

Today’s tale of Visual Studio shenanigans begins with my supervisor coming in yesterday and pointing out a new issue in our development environment since the upgrade to VisualStudio 2010.  Seems he was getting an exception whenever he dragged the content of a data grid out of our application and into Excel 2003. The text of the exception message was:

An exception of type ‘System.Runtime.InteropServices.COMException’ occurred in System.Windows.Forms.dll and wasn’t handled before a managed/native boundary

 Additional information: Invalid FORMATETC structure (Exception from HRESULT: 0x80040064 (DV_E_FORMATETC))

I couldn’t reproduce it under my environment initially. In fact, it initially seemed pretty non-deterministic.  After some isolation testing, we’d learned the following about how to reproduce the exception:

  • It wouldn’t happen with our VS 2008-built app dropping grid data into Excel 2003.
  • It wouldn’t happen with the VS 2010 build dropping data into Excel 2008.
  • It would happen with the same app built under VS 2010, dropping data into Excel 2003.
  I’ve just spent the morning trawling the Web looking for bug reports, forum and blog posts that might shed light on what was happening. I’ve learned that all sorts of things can go wrong that trigger this exception, and many of the bug-reports lodged with Microsoft around the exception tend not to be actioned because they can’t be reproduced. I finally found something that seemed close to what we were experiencing.   The forum contributors reported success by toggling off the debugging option “Break when exceptions cross AppDomain or managed/native boundaries (Managed only)”.
Debug Setting and Options Dialog, Visual Studio 2010

Debug Setting and Options Dialog, Visual Studio 2010

Taking a look at the debugging settings between our different machines, my own setting was unticked, but my supervisor’s was.  We unticked his, and we went back to being blissfully unaware of the exception. The drag-and-drop behaviour worked just fine.  What did I just do though, but flagging this setting off?  Microsoft has this to say on the setting (didn’t really help me much).

The closest I’ve come to grappling with what we might be experiencing comes from a programmer suffering with NUnit exception handling being ignored, and triggering the VS debugger breaking on exception generation regardless of whether there’s programmer handling for the exception or not. For now, I’m only luke-warm about leaving this setting off, if someone stumbles across this posting and has a really good handle on what might be going on here (or can better describe what I’m trading off by unticking this setting), drop me a comment please?

Forcing Visual Studio to open files with the code editor

Alright. I’ve relearned to do this by trawling the internet for the last time.  Yesterday, I upgraded our development environment from Visual Studio 2008 to 2010. At the time it went swimmingly.  Since then, I’ve been plagued with “little” issues like strange reference breakages in assemblies, and the bugbear that this post is about.

There are library files within the solution that contain things that “could” be built up with the VS Designer (sub-classes to DataTable are a perfect example but there are others).  I don’t want or need the designer to step in and try doing its magic on them. It won’t anyway because they occupy the same file as a bunch of other support classes clustered around similar roles and unless a single designable class is at the top of the file, badness happens.

What I want is to get the file to open by default in the code editor instead of the design (GUI) editor that you get if VS notices one of these “designable” classes in a file. The fact that this has come back just after the upgrade makes me suspicious that certain settings were forgotten in the process.

So, first off, here’s a screenshot of a file I’ve just double-clicked on in the solution explorer, containing one of these designable classes, and the design “error” screen I get back:

Visual Studio Designer Error Screen

Visual Studio Designer Error Screen

So, when I hit this issue, I need to right-click on the offending file and choose the “Open With…” popup menu item thusly:

Choosing "Open With..." on a Visual Studio File

Choosing "Open With..." on a Visual Studio File

What I get is a dialog listing a number of editor types I can open the file with (below).  Pay particular attention to the entry with “(Default)” after it.  This is the one you’ll get if you double-click the file from the solution explorer.

"Open With..." Dialog for a Visual Studio File

"Open With..." Dialog for a Visual Studio File

On the right-hand side of this dialog is a “Set as Default” button.  I choose the entry that I’d rather as the default, hit that button and whallah! Opening the file behaves the way I want by default. So, here’s a final screenshot where I’ve chosen the Visual Basic Editor instead of the Windows Form designer as my default editor.

Choosing Visual Basic Editor as the default

Choosing Visual Basic Editor as the default