64-bit ASP.net pages in Visual Studio 2010

Question

Short version :

I use the 64-bit dll (system.data.sqlite) in the Asp.net MVC application in VS 2010. The application works and is fine debugged, but all aspx and ascx pages display errors when editing in Visual Studio 2010 and intellisense does not work.

This is a VS2010 regression error . Does anyone have a job?

(OR)

Does anyone know of a free, reliable, ready-to-release embedded database that doesn't cause a problem with 32/64 bits?

More details

Obviously, this worked in Visual Studio 2008 and it was a known regression error in Visual Studio 2010 for several months . I do not want to return to VS 2008, and I do not want to debug in 32-bit mode.

I have a web application that needs to be debugged and deployed as 64 bit mode because it uses some unmanaged 64 bit dll like system.data.sqlite. In addition, I prefer 64-bit debugging because it allows us to test some cases of large memory usage.

After many attempts, Asp.net will deploy and work just fine. However, all aspx and ascx pages show errors, and intellisense does not work when editing them in Visual Studio 2010. Apparently, this worked in Visual Studio 2008 and this has been a known issue in Visual Studio 2010 for several months . I do not want to return to VS 2008.

There was work posted on SO here , but it didn’t work in my tests, it limits debugging to 32-bit mode, and also hacks a bit (I think this only works for VS Express style sites). Has anyone done this work in a web application or improved it?

For those who are interested, Visual Studio 2010 has two other problems with 64-bit DLLs that I managed to get around.

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

Solution 1 - CassiniDev or Localhost: Debugging using localhost or compiling CassiniDev (openscre cassini variant) in 64-bit mode. I like the simple debug configuration configuration of a new web application using cassini, so I used CassiniDev. You just paste the DLL into C: \ Program Files (x86) \ Common Files \ microsoft shared \ DevServer \ 10.0, and it works (I recommended making a backup copy of the Cassini version that you will be writing on).

Problem 2 - MSTest: By default, unit tests run with MSTest does not load 64-bit DLLs .

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

I am starting to think that the whole installation is too small, and I am on the verge of refusing to restructure my application so as not to use the 64-bit DLL. I am also very disappointed that Visual Studio 2010 caused all these problems. Can someone get MS to correct the regression error they created?

Or,

We want to use an embedded database. Does anyone know of a free, reliable, ready-to-release embedded database that does not cause a 32/64 bit problem?

Answer 1

I am afraid that there might not be work that allows Asp.net 64-bit debugging with a 64-bit unmanaged dll dependency that would not break the web form editor. I think the VS Asp.net team treats 64-bit dependencies as an edge case and fixes the web form editor when they have time ... be warned.

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

I plan to avoid this problem by replacing sqlite with a permanent key / value solution based on esent managed.

Answer 2

I had x64 dll in the bin directory of the website project. The website will be launched in the IIS application pool 64 bit, but it could not start in Cassini. Visual Studio also threw errors (the wrong format) every time I opened a page that made the IDE painfully slow.

Website projects (as opposed to web application projects) are dynamically compiled. However, Visual Studio will use the 32-bit aspnet_compiler. This is true when using the Page Inspector or when using the "Compile Website" menu item. I cannot find a way to change this behavior. IIS on x64 bit uses the aspnet_compiler version for x64 for dynamic compilation, and everything works fine.

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

This can be done using assemblyBinding and probing in the web.config file. privatePath should be a subfolder 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" %>