I am developing an ASP.NET Application and am trying to use the 64-bit driver version of ODBC on my 64 bit win 7 machine, because the deployment server has Windows Server 2008, which is naturally in 64 bit, since Microsoft decided not to make a 32 bit version afaik.
The first issue was an System.Data.Odbc.OdbcException "ERROR [IM014] [Microsoft][ODBC Driver Manager] The specified DSN contains an architecture mismatch between the Driver and Application". Despite the fact, that I am developing on a 64 bit operation system, the compiler seems to have decided to compile for 32 bit. After some research I changed the target platform to x64 in every of my (own) assemblies. I am using NHibernate and Spring.Net, but I read somewhere that 64 bit is no problem for NHibernate. I did not check Spring.Net yet. The compilation began.
I got some warnings that quite every .net assembly is built for another platform, but I read somewhere again that I can ignore these warning and the application should run just fine because the runtime (or compiler?) will figure out the right assembly.
So I tested the application right away and was rewarded with an System.BadImageFormatException (wrong format). It was again an exception concerning 32/64 bit issues although every one of my assemblies is compiled as 64 bit.
I am slowly starting to hate 64 bit. Seriously. Is it that difficult to build an 64 bit application on an 64 bit operation system for a 64 bit server with 64 bit drivers?
Does anybody have a solution or have experience with this issue? I found many workarounds with using 32 bit, but that is not an option here. It has to be a 64 bit solution.
Nevertheless I will continue trying for myself to solve this. I will write any progress here.
Update:
Spring.Net seems to be just fine on 64 bit since the assembly is "dynamically compiled at runtime to the native machine architecture".
i fought with this same error for several hours. My environment was slightly different, but the error was the same. I was using SSRS, Report Builder 3 and SQL Server 2008 R2 on a Win Server 2008 R2 x64 Box
I could create connections and test them successfully in SSRS, but when i would use them, i got the error above. It was resolved when i created a 32bit DSN of the same name and parameters.
I usually try to go other way: If I don't need any native in-proc DLLs, I use AnyCPU. So final program can be used on both x86 and x64. If I need native in-proc DLLs, I always chose x86 32bit version, because it is much easier to make it work correctly, and IMPORTANTLY I don't need any 64bit features. So why 64bit version? I just go to IIS configuration and setup my asp.net application to run in 32bit mode.
For example my current deveopment environment is fully 64bit and works perfectly. But my production server is setup to host my app in 32bit mode. It works perfectly, no 64bit issues. I apologize if this answer is not good for you, but I really never needed 64bit stuff in my asp.net applications.
update: I use 32bit IIS on production server. I am not sure if it is possible to setup asp.net as 32bit in 64bit IIS.
Related
The Story: My website runs in System.Data.OraceClient(I cannot change the dll due to various technical reasons). Now, I have an third party DLL integrated to my website which is 32 bit. When I run from Visual studio everything runs perfectly, but when I publish it to IIS, it throws the above error.
Now Solutions are:
Enable 32 bit in IIS Application pool
When 32bit is enabled the Third party DLL will start to work and System.Data.Oracle client fails with BadImageFormat exception
Disable 32 bit in IIS Application pool.
When 32 bit is disabled System.Data.OracleClient will start to work and the third party DLL will fail with the below error.
Retrieving the COM class factory for component with CLSID {xxxxx}
failed due to the following error: xxxxxx Class not registered
-- This class is registered. That is why it works when 32 bit is enabled.
Now, I am in a situation only one dll will work at a time. Is there a workaround to make my System.Data.OracleClient run when 32Bit is enabled in Application pool without trying to migrate my entire application to Oracle Data Access?
I am thinking the only way to achieve this is to build your web application as 32 bit and that way let it use a 32 bit client. Then everything is 32 bit.
Make sure that your Web Application is built for x86. Do not build as AnyCpu as that will default to the target platform's x64.
System.Data.OracleClient is deprecated for ages and should not be used anymore. It is available only for x86 (32 bit), when Microsoft stopped developing of System.Data.OracleClient 64-bit Windows was not that common yet.
Better use the ODP.NET provider from Oracle, it is available for x86 and x64.
Check also this instruction: BadImageFormatException. This will occur when running in 64 bit mode with the 32 bit Oracle client components installed
I've run into a problem after installing the 64 bit Oracle client onto my Win 7 x64 dev box. I have installed and configured the oracle client and added a reference to it in my library project and it runs without problems when deployed to a Win 2008 R2 server; however I cannot run it in the built-in VS2010 debugger.
The code throws a BadImageFormatException when the .open() statement is called on the connection object.
I figured out that if I will run it in IIS and move the application out of the default application pool, the error goes away for some reason.
However, I can't do this when I'm running the test project (MSTest) and I the result is that I cannot run unit tests against this code. Yes, I can mock it, but I would really like to understand and eliminate this error. There are several cases where I would like to test against some test data in the database.
Any suggestions or links would be greatly appreciated.
Thanks,
Trey Carroll
Here's the answer according to senior dev in my group VS is a 32 bit application so running things in Casini is of course from a 32bit context. When the 32bit Web Appattempts to use the 64bit Oracle Client, it causes the BadImageFormatException. (Apparently deploying to IIS is allowing the Web App to run as a 64bit app and eliminating the conflict.)
So here's the question: How do I run MSTEST unit tests from VS when there are dependencies on 64bit dll's? I could obtain 32bit versions of these, but how would I tell my application to use the 32bit versions for testing/Casini debugging and the 64bit versions otherwise?
I'm trying to get a new DotNetNuke site up and running on our 64-bit server, and I'm encountering the following error message:
"The 'Microsoft.Jet.OLEDB.4.0' provider is not registered on the local machine"
I know from experience that you run into this when you target a 64-bit assembly on a 64-bit machine (there is no 64 bit OLE-DB provider currently). In that case, I simply target the x86 in Visual Studio and everything works fine.
But in this case, the site uses dynamic compilation, so there's no simple place to specify that I need to target x86. Any thoughts?
TIA.
You could change your app pool that you're running that site under to run as a 32 bit application. In the IIS7 manager, its under "Advanced Settings" of your app pool, and then set "Enable 32-bit Applications" to true.
You could also do this with AppCmd from a console with the following:
appcmd apppool set /apppool.name:MyNukeSite /enable32BitAppOnWin64:true
In IIS6 - you could try something like this (2 lines here, run aspnet_regiis when finished changing the metabase value)...
cscript %SystemDrive%\inetpub\AdminScripts\adsutil.vbs set w3svc/AppPools/Enable32bitAppOnWin64 1
aspnet_regiis.exe -i
See the following for more info:
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/5d306956-b2a2-4708-9bb9-72a395d474bb.mspx?mfr=true
http://blogs.msdn.com/irfanahm/archive/2008/12/15/how-to-use-a-32-bit-dll-in-asp-net-page-which-is-hosted-on-64-bit-iis.aspx
http://support.microsoft.com/kb/895976
HI, Now the Microsoft has released the 2010 Office System Driver Beta: Data Connectivity Components which is supported both in 32 bit as well as 64 bit OS. So using this driver instead of the traditional Microsoft.Jet.OLEDB.4.0 driver will give us a 64 bit application running on a 64 bit server (that is what we really need).
Though this is in beta, it worked fine for me.
You can download this driver from 2010 Office System Driver Beta: Data Connectivity Components
Thnks
You shouldn't try to target your application to 32-bit in which case you are losing the advantages of using 64-bit system. As aaa has pointed out, you can use the latest Access Database Engine 2010 to address this issue. Please refer to my blog post for complete solution.
Hope it helps.
My development machine is Win XP Pro 32 bit and production machine is Windows Server 2008 (64 Bit) with IIS 7. On my development machine I want to compile ASP.NET (Using aspnet compiler) to 64 bit byte code.
Can anyone please tell me how to do that? Please do not suggest any way to run 32 bit application on 64 bit environment.
I want 64 bit application to be compiled on 32 bit machine so that when it runs it will take full advantage of 64 bit O/S without any emulation.
Leave the target platform at AnyCpu and .NET will automatically run natively on 64bit when executed on a 64Bit operating system
Clarification:
(this started out as a comment but I thought it might be interesting for the question as well)
Actually you never compile to a special architecture. You always compile to IL.
That's something like Java Bytecode. And that bytecode is the same for 32 bit and 64 bit.
The Virtual Machine (.NET Framework) on the machine the code gets executed then compiles the IL to actual machine code while running (through the Just In Time compilation). So, no matter where you compile, you'll always end up in IL that's bit-ignorant.
The setting in .NET is only an instruction in IL that tells the JIT (Just in Time compiler) to specifically use 32bit/64 bit. By flipping that one bit in your assembly you could still execute it in AnyCpu or x64 without recompilation.
This setting is only used and needed in case you call out to native code that isn't bit-ignorant (when interacting with COM components or doing p/invoke calls)
There's an option in Visual Studio 2013 now to direct IIS Express (which is usually used for debug) to run in 64 bit mode.
It's at Tools -> Options -> Projects and Solutions -> Web Projects -> Use the 64 bit version of IIS Express…
.net apps will re-target themselves for the target machine environment assuming that you didn't specifically choose to compile in 32-bit mode. This can be found under the project build options.
Are there any compatibility issues that would prevent this from working? Do I need to have a 32-bit VM to use when working on projects for this team?
No. Should work perfectly well.
Read a little here: http://msdn.microsoft.com/en-us/library/ms973190.aspx
I run Vista 64 and the other members of my team run XP 32 bits, the only issue we've had so far was with a third party COM-component where the interop assembly wasn't easy to generate on the 64 bit machine. Once it was generated it screwed up the other machines. That was fixed by generating the interop assembly on the 32-bit machines and checking it into source control.
I heard in the latest .Net-rocks podcast that setting x86 instead of "Any CPU" in the build configuration should resolve a lot of problems, but since I haven't had any problems other than the one I described I have not yet tried that.
It doesn't matter what your environment is, develop on whatever machine you wish. I would be concerned about the QA, staging and production environments. If they are all 32 bit, I would want a 32 bit VM to test my code.
I'm not sure about collaborating with other developers in a different windows 32/64-bit environment, but I can speak about deploying an .NET application that was developed in Windows XP 32-bit on a Windows 2008 64-bit server.
The only problem I had was with an application that relied on a 3rd-party assembly. We only had a 32-bit version of the assembly. So, in order to run our application in a 64-bit environment, I had to compile my project for x86 (as you described). It solved everything.
All other applications I was able to get running without changing a thing (they were compiled in the 'Any CPU' mode.
I suspect you won't have problem unless you have some external assemblies. If that's the case, then you will either have to recompile them or simple force your project to compile to x86.
I know that doesn't definitely answer you question, but hopefully it helps.
Andrew