.NET Framework Bookmark and Share   
 index > 64-Bit .NET Framework Development > any way to determine x64 x86 at runtime ?
 

any way to determine x64 x86 at runtime ?

Problem due to Jet not being 64bit compatable.

Basically I need to determine at runtime whether my application is running 64bit or 32bit.

I plan to have the 64bit users use a sqlexpress database, and the 32bit users connect to the "legacy" access database.

But I need to know at runtime which is wich, since there is no way to connect to the access database from my application when compiled with "AnyCPU"

foxjazz2

Access is not RDBMS so it is not practical to expect 64bits provider for such none standarddatabase, you have the choice of using only SQL Server Express for both your 32bits customer and 64bits customer. If you decide to do less work to use Access database for your 32bits customers you just need configuration section that connects to Access for 32bits and Express for 64bits because both are still 32bits applications which must install in WOW64 for the 64bits box and you can still install Access in WOW64 in 64bits box you just need to install MDAC and reference MDAC for your Vista 64bits customer because XP and Win2003 64bits comes with MDAC just make sure Win2003 is up to Sp2.

Then just create two deployment packages one for 64bits to install in WOW64 and a 32bits version for 32bits boxes, the reason is SQL Server Express at the moment you have versions you can install in 64bits boxes but it is a 32bits application server.

Caddre
Caddre's advice is quite reasonable. But if you really want to do this, check out Bit specific code in agnostic assemblies???
Feng Chen

Access is not RDBMS so it is not practical to expect 64bits provider for such none standarddatabase, you have the choice of using only SQL Server Express for both your 32bits customer and 64bits customer. If you decide to do less work to use Access database for your 32bits customers you just need configuration section that connects to Access for 32bits and Express for 64bits because both are still 32bits applications which must install in WOW64 for the 64bits box and you can still install Access in WOW64 in 64bits box you just need to install MDAC and reference MDAC for your Vista 64bits customer because XP and Win2003 64bits comes with MDAC just make sure Win2003 is up to Sp2.

Then just create two deployment packages one for 64bits to install in WOW64 and a 32bits version for 32bits boxes, the reason is SQL Server Express at the moment you have versions you can install in 64bits boxes but it is a 32bits application server.

Caddre

Caddre, just say you don't have an answer instead of stating the obvious.

I asked simply if there was a way to tell at "runtime" whether or not the program was running as x64 or x86. Instead you have stated stuff about distribution, and how you think I should handle my current situation while knowing nothing about my current situation.

Does anyone know a function .net call at runtime that determines what cpu I am using so that I don't have to wait for the try catch to fail when trying to connect to an access database?

Also what makes you think I deploy my application using packages?

foxjazz2

(I asked simply if there was a way to tell at "runtime" whether or not the program was running as x64 or x86.)

These in .NET are not runtime options but VS2005/8 build options that is the reason for my reply and the configuration class can connect to database of your choice at runtime.

Caddre

if OS = 64bit then

OleDbConnectionAIMFile.ConnectionString = "sql server"

else

OleDbConnectionAIMFile.ConnectionString = "Access"

end if

Does this code make it any clearer what I am trying to accomplish?

foxjazz2

That may be in your configuration class but I think you may get BadImageformatexception in x64 boxes because you are passing references to Access without taking care of the 32bits ODBC connector in your 64bits box. I have told you how I will handle it because I want to avoid this exception but you have the right to do what you want.


http://msdn2.microsoft.com/en-us/library/system.badimageformatexception.aspx

Caddre
Caddre's advice is quite reasonable. But if you really want to do this, check out Bit specific code in agnostic assemblies???
Feng Chen

Thanks feng, I will use it.

I don't really understand Caddre's reply.

All I intend to do is avoid a conflict that I have. I probably shouldn't be running vista 64 in the first place, but I am. And with regard to that I am having to use sql express myself to access data instead of access. While the x86 machines are accessing the data via MS access because it's easier to distribute.

I don't want my program to throw an exception, so depending on the environment, I want to go after the correct data source.

Thanks everyone for the info...

foxjazz2

The very simple way: check the size of the IntPtr.
If the size is 8 byte, this must be a 64-bit process, otherwise, if size is 4 byte, it's a 32-bit application mode
xidar

You can use google to search for other answers

Custom Search

More Threads

• FolderBrowserDialog SEHException on 64-bit machine
• "not a Microsoft.NET module" error trying to add a valid x64 assembly to VS 2008 ToolBox
• API for detecting if a printer driver is 64 Bit [without Admin rights]
• x64 .NET Framework Installation
• RSACryptoServiceProvider FatalExecutionEngineError in Vista 64 - looks like a bug
• Targeting both 32bit and 64bit with Visual Studio in same solution/project
• Problems Compiling a solution on 64-bit OS
• Installer error whit aspnet_regiis.exe
• ASP.NET 2.0 app reports Configuration Error: The specified module could not be found. (Exception from HRESULT: 0x8007007E)
• What's win32 and 64-Bit?