Monday, May 3, 2010

Issues with Visual Studio 2010

ACTION ALERT: See the end of this post for a request to vote on a Visual Studio bug that is affecting Gallery Server Pro development. I need your help!

UPDATE 2010-5-5: Microsoft has confirmed they can reproduce the issue and is investigating it. Keep voting to keep the pressure on!

Visual Studio 2010 just came out, so I installed it, opened up the Gallery Server Pro solution, and took a peak around. The first thing I noticed is that all my ascx and aspx pages had squiggly marks all over the place:

Visual Studio 2010 error

When I hover over the @Control directive in the first line, I see this message:

"ASP.NET runtime error: Could not load file or assembly 'System.Data.SQLite' or one of its dependencies. An attempt was made to load a program with an incorrect format."

That is a tell-tale sign that Visual Studio is trying to load the 64-bit version of System.Data.SQLite into its own 32-bit process. Kind of makes sense, but this worked fine in VS 2008.

This problem also seems to cause issues with custom user controls and third party server controls. For example, when I hover over the uc1 user control declaration (you can see it in the screen shot), I see this message:

"Unrecognized tag prefix or device filter 'uc1'"

I also lose intellisense on these controls.

Despite these problems in Visual Studio, these errors seem to be more cosmetic than a show-stopper. I can compile the solution and run it in IIS. It is annoying to lose intellisense and the squigglies are making me sea sick, but at least I can continue working.

If you are working with the Gallery Server Pro source code on a 64-bit operating system, you may run into this as well. Not a big deal, but if it drives you nuts, here are the known workarounds:

1. Use Visual Studio 2005 or 2008 instead.

2. Use a 32-bit OS.

3. If using a 64-bit OS and VS 2010, avoid IIS (which is 64-bit) and stick with the built-in Cassini web server (which is 32-bit). Rename the dll in TIS.GSP.Data.SQLite\assemblies\x64 to something else such as System.Data.SQLite_x64.dll (or delete it) and then recompile. This forces Visual Studio to use the 32-bit version of System.Data.SQLite.dll.

None of these workarounds are very attractive to me, so my best hope is for Microsoft to fix this in a service pack. To start this process, today I submitted a bug report with Microsoft. To make this a priority for Microsoft, I need lots of people to validate the issue and vote on it. So I ask for your help. Please go to the bug report and vote for it. Thanks!