threading excel write with c#

Question

0.00/5 (No votes)

See more:

Hi,

I would like to know how to determine if the Ace OLEDB Driver is 32 or 64bit installed on the target PC and then tailor the 32 or 64 bit build of my program which writes to excel with OLEDB.

Currently on 64 bit office with 64bit ACE I need to change the configuration in visual studio from x86 to x64 and vice versa.

Is there any method to detect 32/64bit installation and do you need in the setup project to write a script or can you dynamically write code to alter the 32/64 build that way.

Thanks,

Jase

Posted 14-Jul-12 18:47pm

AU Jase

Updated 21-Jul-12 12:59pm

v2

Add a Solution

Comments

Sergey Alexandrovich Kryukov 15-Jul-12 1:10am

Not clear. It looks like you think interop is the alternative to threading, but they are not related. Could you create some complete but short code sample? If you could, use "Improve question".
--SA

AU Jase 15-Jul-12 1:38am

some pseudo code:

[list : aa,bb,cc]
[DATA TABLE : COLUMNS aa,bb,cc, etc with rows 0--n]
I want to write list(n) spreadsheeets based on for (0) column AA of datatable,etc
so I do in a loop
WRITE DATA TO EXCEL (FROM LIST) , Create Excel Interop/OLEDB , etc
WRITE TO EXCEL data in datatable based on LIST column criteria
DISPOSE EXCEL INTEROP/OLEDB, etc
then loop

and all the above is in a function call within a backgroundworker thread

i get issues with empty datatable, row in datatable deleted exceptions

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Dave Kreskowiak · Accepted Answer · 2012-07-21T13:33:00

Solution 2

If you compile your app to target "Any CPU" it'll run 32-bit on 32-bit procs and 64-bit on 64-bit procs.

If you compile your app to target "x86", it'll run 32-bit only no matter what O/S it's running on.

But, if you compile "Any CPU", since you can't combine 32- and 64-bit code in the same process it's kind of pointless to check to see what's installed. You should, though, be checking to see what bitness your code is running as. That's easy enough to do by checking the sizeof an IntPtr. It'll be 4 bytes wide if your code is running 32-bit and 8 bytes if 64-bit. Then it's just using the correct connection string.

Again, you don't check what Office or driver is installed, you check what your code is running as.

Posted 21-Jul-12 13:33pm

Dave Kreskowiak

Comments

AU Jase 21-Jul-12 20:14pm

Hi Dave,

I see where you are coming from, but this is the problem I am thinking about:

1. You have 32 bit Ace Excel OLEDB 12.0 driver installed, yet you have a 64bit binary of the program in c# (incompatible) on win 7 x64. so you have a problem
(by virtue of installing 32 instead of 64bit office 2010)

In order to solve this issue you will need the x86 build.

So do you:

In the setup project (installer) configure it to check and then copy the relevant x86 or x64 prebuilt binaries across ?

or do you have a routine in your code to check and tell configuation manager to compile the appopriate build ?

The reason for asking is : x64 build using OLEDB 12.0 will fail if using 32bit installed OLEDB (office 2010) and vice versa

the connection string is generic for either 32/64 bitness, is it decided by the exe build and not the connecting string ? on a 64bit exe, with a 32bit installed drivers, I need to manually change to 32bit to get it to work, and if I was using 64bit drivers with 32bit exe I need to change it to 64bit to get it to work, regardless the connection string stays the same

else I get ISAM, ACE, OLEDB exceptions

Dave Kreskowiak 21-Jul-12 22:22pm

You're going about this the wrong way.

This problem is solved at install time, not run time. If you install the appropriate runtime, found at http://www.microsoft.com/en-us/download/details.aspx?id=13255, you don't have to worry about Office being installed at all and your app would still have everything it needs to work.

AU Jase 21-Jul-12 20:17pm

could you probe the installed Office 2010 OLEDB registry entry to see if its 64 or 32 bit and use it as a conditional exe to run either the 32 or 64bit version of your source exe ? If so , how would this be achieved ?

AU Jase 21-Jul-12 23:55pm

I understand that, just how do we know if 32 or 64bit office is installed so the appropriate binary is used, cannot use 64bit exe if 32bit access oledb is on target machine, if x64 OS no guarantees 64bit access oledb is installed !

Just covering all bases

AU Jase 21-Jul-12 23:56pm

Tried you int detection if left on default config it's 64bit on 64bit OS as expected but my office is 32bit so it still fails

Dave Kreskowiak 22-Jul-12 14:14pm

You're not listening to me. It doesn't matter what version of Office is installed if you install the pre-req I gave you the link for. If the SYSTEM is 64-bit, you install the 64-bit version of that pre-req. If it's 32-bit, you install the 32-bit version. This will work even if office is not installed.

AU Jase 21-Jul-12 23:57pm

64bit exe trying to access 64bit access oledb where none exists
If I change to x86 build , fixed! But if deployed to another target where 64bit oledb exists it will fail as then build is x86, see my dilemma, no universal solution

AU Jase 22-Jul-12 16:27pm

Dave,

You not listening to me too buddy. If I was the sole user, then I will just install the right pre requisite to make OLEDB work. But eventually I will deploy it to an office environment with mixed Operating Systems on Windows, could be as old as XP, could be vista 32/64 could be win7 32/64, if its 64 bit, there ARE NO GUARANTEES that if you got win7 64, you install office 2010 64, so I am just covering all bases , trying to figure out the multitude of configurations and if there is a universal way to do it. In an ideal 32bit environment no worries it can only run 32bit OLEDB so I just build for 32bit x86, but if its 64bit, 2 scenarios , 32bit oledb or 64, if I complile to config, and it is running 64bit OS, and oledb is 32, I am stuffed, as the config will detect x64 and then build to that.

I think I will need to investigate the setup and deployment option in VS and find how to do scripting or stuff, someone mentioned the Win32API to try and detect using http://stackoverflow.com/questions/495244/how-can-i-test-a-windows-dll-to-determine-if-it-is-32bit-or-64bit

or use the registry.

Please understand my dilemma !

Dave Kreskowiak 22-Jul-12 17:47pm

Oh, I do understand the problem. In my environment, I have to write code for 12,000 machines of varying O/S versions and bitness.

I told you how to solve the problem. It's one I've used more than once. You're over-thinking the solution.

AU Jase 22-Jul-12 16:29pm

I need a process to target the OLEDB version and hook into config manager in VS to tell it eg. OLEDB32 found, compile x86, if OLEDB64 found (office 2010 x64) then if 64bit OS ( cant run in x86), leave as is

OLEDB also I am referring as Office 2010 Access Components/Runtime, whatever ACE Driver

So I need to only worry , IF 64BIT OS (IF 32BIT OLEDB, compile X86) else compile X64 (BUILD, forgive me wording)

Dave Kreskowiak 22-Jul-12 17:48pm

You shouldn't be recompiling a damn thing based on what you find on the target computer. Man, you're over-engineering the solution.

AU Jase 22-Jul-12 23:57pm

could you explain to me if a target machine has 32bit office 2010 meaning they have 32bit OLEDB, and if they are running x64 win7, how it should work and not fail (due to build being x64 due to config manager detecting 64bit OS and the 64bit OLEDB is missing ?)

Dave Kreskowiak 23-Jul-12 8:03am

I already did. The version of Office on the machine has absolutely no bearing on the application at all, IF you install the pre-req software I linked to.

http://www.microsoft.com/en-us/download/details.aspx?id=13255

Really, the solution is simpler than I originally posted. You compile your app AnyCPU. Then you create two installers, one x86 and one x64, and include your compiled app in both of them. Then you include the 32-bit version of the drivers I linked to in the x86 installer and the 64-bit version of the drivers in the x64 version. Depending on which bitness of Windows you're installing on, you use the appropriate version of the installer.

As I've been saying all along it does not matter which bitness, or even if, Office is installed! You're not using Office!

You're using a database driver.

AU Jase 23-Jul-12 17:04pm

Dave , I know where you are coming from, I was thinking using the setup/installer too but my problem is: scenario : 64bit win7 , using config any CPU , no worries x64, if the machine has 32bit office 2010, you go try to install 64bit access components it will throw an error incompatible/ need to uninstall 32bit components first. If you can figure out office bitness then this hassle will be avoided

Dave Kreskowiak 24-Jul-12 10:20am

OK. Then it's easy to figure out which Office is installed.

Your installer custom action code will look in the registry under HKLM\SOFTWARE\Microsoft\Office\verionfolder\Registration
If a key listed under there is {90120000-0011-0000-0000-0000000FF1CE} its 32-bit Office. If it's {90120000-0011-0000-1000-0000000FF1CE} it's 64-bit Office.

You still need two seperate installers for your app, one that runs on 32-bit Windows, with your app compiled x86, and one that runs on 64-bit, with your app compiled as both x86 and x64 in two seperate features.

Your custom action code will have to make the determination which version of the app to install.
Keep in mind that for a 32-bit Office on 64-bit Windows, the about registry path will change to HKLM\SOFTWARE\Wow6432Node\Microsoft\...

AU Jase 24-Jul-12 16:38pm

Thanks Dave,

Finally on the same understanding, what would be great is a mechanism to hook into the vs config manager during install time and after detection tell it to compile x86 or x64. Is it possible? If it is I need only one binary exe, if can hook on build time even better, does c# have pre processor directives like c/c++ ?

Dave Kreskowiak 24-Jul-12 19:38pm

Sooooo, you're going to ship Visual Studio with your app?? Isn't that a bit like shipping the assembly plant with a car?? That's a bit of a heavy download.

No, C# does not have preprocessor directives like C/C++.

AU Jase 24-Jul-12 19:46pm

So Dave,

this works : have 2 builds, one x86, the other x64
the setup installer, you add code to tell it which to distribute and you bundle the appropriate Access 2010 OLEDB x86/x64 redistributable ?

Dave Kreskowiak 24-Jul-12 19:53pm

Almost. You have to have two seperate installers. One for 32-bit Windows and one for 64. A 64-bit installer wont work on 32-bit Windows.

The 32-bit installer is easy. There's no checking for anything. Just install the pre-req and install the 32-bit version of your app.

The 64-bit installer is more complicated as it has to determine which Office bitness is installed if any, then you can install the pre-req if needed and then the appropriate version of the app.