We are moving to an all-64-bit development environment. Unfortunately VS 2008 and, more importantly, its built-in web server, run in 32-bit mode. When debugging code that references 64-bit assemblies - Oracle.DataAccess, for example - we experience the dreaded System.BadImageFormatException.
Can anyone offer any strategies for debugging code with 64-bit dependencies in VS? I suppose we could use a 32-bit Oracle provider, but we would like to emulate the production environment as closely as possible.
I have a similar setup on 64 bit Vista where I have the web site deployed in IIS - this site has in been successfully run and debugged in both 32 and 64 bit.
The biggest problem I have found is working in a mixed environment where some members on the project team are still on 32 bit Windows (both XP and Vista).
This causes headaches with project references to Oracle.DataAccess which I have only managed to solve with bindingRedirect entries in the web.config file in order to point to the correct version of the assembly.
If you use IIS7 you can choose 32/64 bit mode. You will then have to have your projects kick up with IIS instead of cassini which takes a little bit of work, but I think it will solve the problem with Oracle at least. Honestly I don't know how that would all work when attaching at 32bit debugger to it.
We use VMware hosts to give each of our web site developers their own virtual web server. You can use full IIS (as #KevinWon suggested) and install a 64-bit version of the debugger on them. I don't know the specifics of what our guys do - I found this out over a coffee the other day.
Set up an local IIS on your computer and set it to run in 32bit mode
http://kb.parallels.com/en/2131
If you enable the Debuging mode you can work with it, just like you would with the integrated development server. But you don't have to mess with the 32/64bit assemblies
Related
We are debugging a 32bit application, which connects to oracle using 32bit libraries.
We are able to debug in IIS by setting our application pools to 32bit and using IIS debugging.
We would like to be able to use cassini.
At the moment we are getting TNS listener problems connecting to oracle on 64bit windows 7 using cassini as the debugger.
We have tried building 32bit targets, but this does not help.
There are obviously idiosyncratic issues with this mixed architecture setup. Is there an alternative to cassini, or a way of forcing cassini to be fully 32bit.
The same problems do not occur on a 32bit O/S.
Thanks
Regards
Craig.
You can pull the source for CassiniDev and build as x64. It serves as a drop-in replacement for the VS 2008/2010 dev servers.
So I've been developing on Windows XP Visual Studio 2008. I guess it is building my C++ app in 32 bit mode. When I run the program on my new Windows 7 64 bit box, it gets half way through loading a then throws an access violation error. So, I loaded all my development tool and recompiled the project on Windows 7 to find the crash site but it works perfectly! What? How do I make my app work on x64? Do I have to release two seperate versions? I know I can target 64 bit but I don't like two separate executables. I've searched but keep getting the two version solution or everything .net. This is a native C++. is there an x86 flag somewhere?
"Do I have to release two seperate versions?"
It depends on what your app does. The majority of 32bit apps work just fine in WoW mode.
"is there an x86 flag somewhere?"
Yup. Open up the configuration manager (Alt-B, O) and you will likely see a win32 in the platform selection.
Why your app crashes is going to take some debugging. You should be able to attach the debugger to the 32bit version on the 64bit OS.
Have you considered the possibility that you may be trashing memory? From the way that the application happens to be loaded into memory, it may be that the 32-bit app on 32-bit Windows and the 64-bit app on 64-bit Windows "get lucky", i.e. no important memory locations are overwritten, whereas the 32-bit app on 64-bit Windows is less lucky and crashes.
To find out if you are indeed trashing memory, you can use tools such as Purify and Valgrind.
As the others' answers already said, it is very likely that the application has bugs that are being hidden in one environment. A good tool that has a low cost of entry in terms of learning curve is Microsoft's application verifier. That along with the debugging tools can provide a very good start. Take a look at the gflags utility.
I keep running into all sorts of nuances between the "web site project" versus "web application project" - here is the latest for me:
I've inherited a Visual Studio 2005 solution with several class library projects (a DAL.dll, a Biz.dll, etc.) but this is all "fronted" by a web site project rather than a web app project.
While the web app project provides a Platform Target dropdown list (Any CPU, x86, x64), the poor web site project appears to offer nothing like that. Is there a way to ensure the web site runs as x86 when hosted on a 64bit IIS machine?
..The bigger picture of why I am asking this:
The website runs on a 64bit machine (Win Server 2003) and [I have just learned] cannot load a 32bit COM object which I believe has been wrapped with a Runtime Callable Wrapper. Because it cannot load this piece, a web.config setting is set to avoid the runtime load error by bypassing the load of this 32bit dll (but all of the functionality of COM dll is therefore "lost" when the site is running on a 64 bit machine).
So, in summary, I presume the web site on the 64bit machine must be running in IIS as a 64bit app and that if I could just get the site to run as 32bit instead, then it could load the COM dll and therefore execute that functionality of the application.
NOTE: I have been and still am doing research here in preparation for a quick uptake when I get access to the actual development environment so much of my question is based on piecing together parts of my [anticipated] problems to be faced soon. Thanks.
As far as im aware, under server 03 you cant have 64 bit and 32 bit application pools in IIS side by side.
You can force it run in 32bit mode but this would affect all application pools, and therefore all sites / apps. This sounds like it should fix your COM issue but it might have an effect on any thing else running on that box so be aware of that. To be fair the chances of switching from 64 bit down to 32 effecting things are less than vice versa. The only common thing that springs to mind that must be ran in a 64 bit applicaiton pool is Exchange 07. Having said that im a dev, not a server admin.
If your sure, look here
Btw, server 08 can rock both 64 bit and 32 bit app pools simultaneously.
There appears to be no x86/x64 target for web site projects, only the Any CPU target. You therefore have to control the bitness of your website by controlling the bitness of your app pool.
On Windows Server 2008 or Windows 7, if you want to make an AppPool 32-bit, go into the IIS Manager > [Server Name] > Application Pools > Advanced Settings. Set "Enable 32-Bit Applications" to "True" for the app pool you want to run as an x86 process.
Note that you will have to take other WOW64 considerations into account, for example, registry settings accessed by your web app will now use the [HKLM\Software\Wow6432Node] key instead of the [HKLM\Software] key.
Has anyone already tried this, anything particulair that I need to be aware of?
Yep, been running it for a while and I haven't hit any problems yet. Can't say I've use it all day every day, but I've built WPF, WinForms, Web and Console apps with it for testing various things and haven't had any hitches.
I have it on my Dell X1, which is effectively my "NetBook", and it's really pretty rapid. The only glitch I have had at all is some problems with graphics acceleration, but that's down to the Intel driver I'm using being an old XP driver, and it was easily worked around.
I've been running it inside a VM in Parallels Desktop 4 on a MacBook Pro. Absolutely no problems to speak of.
(There's no sound in Windows 7 as virtualized through Parallels, which is a known issue — but not very pertinent to the operation of Visual Studio.)
Jeroen,
I've been unable to install the 2008 Team Developer edition - keep getting a permission error. I was, however, able to insall the 2008 Team Database edition. I normally install both editions, so am kind of bummed about not getting the Developer edition to install. Screenshot of the error is here if you're curious.
No Problem with team edition, but only using it for web projects.
I've been using it at work since RC1 and have not run into any issues. Have developed a WinForms app, a WebForms site and now working on a MVC project.
I have had zero problems running Visual Studio 2008 Pro on 32 bit and 64 bit editions of Windows 7 for full-time C++ development.
If the application you are developing doesn't behave correctly under UAC you may will need to run the IDE as admin otherwise it won't run correctly under debug (this is the applications problem, not Windows 7 or Visual Studios).
Others seem to have problems with access rights/permissions, this should also be fixable by running the IDE as admin (via right click) or more permanently via the compatibility tab in the shortcut properties.
I don't know why this happens, is probably related to their particular user account settings.
Can someone tell me why I don't have all of the dev studio windows available to me when I develop on a 64-bit platform? I upgraded my dev desktop box to server 2003 x64 to match our deployment platform. Since then (I'm using VS2005) I've noticed that several windows aren't available. I can't view Processes (which is the most annoying) so I don't know which processes I'm attached to. I can attach to a process fine, but it won't show me what is already running under the debugger. There are others, but that's the one that sticks out in my mind at the moment.
My question is where are these limitations of developing under 64 bit documented (assuming they are)? (Of course, I also get the "Edit/Continue" warning dialog all the time telling me that doesn't work in 64-bit)
Also, is VS2008 any better under 64 bit?
Follow-up: Apparently my question is a little bit vague. I'm developing a 64-bit app on a 64-bit development environment. "Recompile it in x86" doesn't solve my problems.
Follow-up #2: I'm giving it one more shot. I WANT TO DEBUG A 64 BIT PROGRAM ON A 64 BIT ENVIRONMENT AND I DON'T HAVE ALL OF THE VISUAL STUDIO FEATURES SHOWING UP. HOW DO I GET THEM?
Follow-up #3: I just installed XP 64 (previously I was using Server 2003 64-bit) and those features all showed up again (Process window, etc). Apparently the server version of windows doesn't provide all of the dev features.
Can anyone tell me why?
"Edit/Continue" can work if you change the build setting to X86 :)
Here was the suggestion from StackOverflow about it.
I had some problem with NUNIT when debugging code. The solution was to use the special program in the \bin\ folder Nunit-x86.exe for old code built in x86 and use the Nunit.exe for x64 built.