4

Short Version:

I'm using a 64bit dll (system.data.sqlite) in an Asp.net MVC app in VS 2010. The application runs and debugs fine, but all the aspx and ascx pages show errors when editing in Visual Studio 2010 and intellisense doesn't work.

This is a VS2010 regression bug. Does anyone have a work around?

(OR)

Does anyone know of a free, reliable, production ready embeddable database that doesn't cause a 32/64 bit problem?

More Details

Apparently this worked in Visual Studio 2008 and this has been is a known regression bug in Visual Studio 2010 for several months. I don't want to revert to VS 2008 and I don't want to debug in 32 bit mode.

I have web application that needs to debug and deploy as a 64 bit mode because it uses uses some unmanaged 64 bit dll's like system.data.sqlite. Also, I prefer debugging in 64 bit mode because it allows us to test some high memory use cases.

After a lot of fiddling, Asp.net will deploy and run just fine. However all the aspx and ascx pages show errors and intellisense doesn't work when editing them in Visual Studio 2010. Apparently this worked in Visual Studio 2008 and this has been is a known problem in Visual Studio 2010 for months. I don't want to revert to VS 2008.

There was a work around posted on SO here but it didn't work in my tests, limits debugging to 32bit mode, and also feels a bit hacky (I think it only works for VS Express style websites). Has anyone made this work in a web application or have a better work around?

For those who are interested Visual Studio 2010 has two other problems with 64bit dlls that I have managed to work around.

Problem 1 - Cassini: Cassini can only debug in 32 bit mode

Solution 1 - CassiniDev or Localhost: Debug using localhost or compile CassiniDev (an opensoure variant of cassini) in 64bit mode. I like the zero config simplicity of debugging a new web app with cassini so I used CassiniDev. You just stick the dlls in C:\Program Files (x86)\Common Files\microsoft shared\DevServer\10.0 and it works (I recommended making a backup of the Cassini version you will be over writing).

Problem 2 - MSTest: By default unit tests run with MSTest fail to load 64bit dlls.

Solution 2 - AnyCPU & 64bit host process Instructions here, set local.testsettings to AnyCPU & 64bit host process

I'm starting to think the whole setup is too little hacky and I'm on the verge of giving up and restructuring my application to not use a 64bit dll. I'm also really disappointed that Visual Studio 2010 caused all these problems. Can somebody make MS fix the regression bug they created?

Or,

We want to use an embeddable database. Does anyone know of a free, reliable, production ready embeddable database that doesn't cause the 32/64 bit problem?

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
Glenn
  • 1,234
  • 2
  • 19
  • 33
  • I have also seen this solution but I'm not sure that it fits my use case. http://scottbilas.com/blog/automatically-choose-32-or-64-bit-mixed-mode-dlls/ If anybody feels comfortable recompiling sqlite to use the proxy dll thing I would love to hear how it goes. – Glenn Nov 03 '10 at 22:56
  • I'm leaning towards ManagedEsent http://managedesent.codeplex.com/ I think its safe to rely on windows servers having the dlls required for Microsoft.Isam.Esent.Interop Its more a key value store than a db but I think it may fit my purpose and put this bittiness behind me. – Glenn Nov 04 '10 at 07:05

2 Answers2

2

I had an x64 dll in the bin directory of a web site project. The web site would run in an IIS 64 bit application pool, but it failed to run in Cassini. Visual Studio also threw errors (incorrect format) every time I opened a page which made the IDE painfully slow.

Web site projects (unlike web application projects) are dynamically compiled. However Visual Studio will only use the 32 bit aspnet_compiler. This is true when using the page inspector or when using the Compile Web Site menu item. I can find no way to change this behavior. IIS on a x64 bit will uses the x64 version of aspnet_compiler for dynamic compilation and everything works great.

The only workable solution to get Visual Studio to stop throwing errors was to remove the x64 dll from the bin directory and load it dynamically at run time as stated here.

This can be accomplished by using assemblyBinding and probing in your web.config file. The privatePath must be a sub directory of your application directory and not outside the application directory. 

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="dlllocation" />
    </assemblyBinding>
  </runtime>
<configuration>

You also need to add code to any aspx file BEFORE the @Page directive 

<%@ Assembly Name="fileNameWithoutExtension" %>
<%@ Import Namespace="NameSpace" %>
kheld
  • 782
  • 5
  • 14
0

I'm afraid there may not be a work around that enables 64bit debugging Asp.net with a 64bit unmanaged dll dependency that won't break the web forms editor. I'm thinking the VS Asp.net team considers 64bit dependencies an edge case and will fix the webforms editor when they have time... be warned.

You can always debug in 32bit mode and then deploy 64bit without proper testing.

I'm planning to avoid the issue by replacing sqlite with a persistent key/value solution based on managed esent.

Glenn
  • 1,234
  • 2
  • 19
  • 33