Develop Reference

Migration from 32 bit to 64 bit -> Microsoft.Jet.OLEDB.4.0' provider is not registered on the local machine

We have 32 bit windows application developed with vs2005.In this application their is facility were user can upload his details with xls file.
As demand we need to support to 64 bit machine,which we have done.
The only problem we faced is that when user try to upload file system throws an error "'Microsoft.Jet.OLEDB.4.0' provider is not registered on the local machine"
Can u guide me for the same

Microsoft's Jet driver does not exist in 64-bit form. You have two options:
Compile your application to 32-bit only. This will run on 32-bit workstations and WOW64 on 64-bit machines, so you still get the benefit of "supporting" 64-bit machines even though it is running 32-bit.
Move to the ACE driver, which comes in 32-bit and 64-bit variants.
Option #1 is probably what I would recommend. This requires the least changes to your application, and your application will likely have very little benefit by running native 64-bit. Secondly, if you do move to ACE for the purpose of supporting 32-bit and 64-bit, now you need to worry about two different ACE drivers, the 64-bit one and the 32-bit one.

I had a similar problem - see How to enable reading C# Excel files on IIS (reading them locally on the machine where IIS is running works fine)?
Rewriting everything using EP Plus for XLSX and NPOI for XLS turned out to be much easier than using Microsoft stuff. Both are freeware and work well.

Problems with the library IFilter

I want to use the IFilter interface to extract and then search the text from different documents. The IFilter interface fits this need perfectly, but there is an issue with 32/64 bit components.
The host OS is 64-bit. The application is 32-bit. I want to extract text from a .docx file, so I try to install the 32-bit Office 2010 Filter Pack. The installer fails with a message: 'The MSI Installer type does not match the platform architecture.'
When I install the 64-bit version of the Filter Pack, the 32-bit dlls are not installed so the filters are still not available. How do I install the 32-bit filters on a 64-bit system? it's possible ?
Thanks a lot in advance

There is no support for installing the 32-bit filters on 64-bit Windows. The only solution you have is to install the 64-bit filters and create a 64-bit out-of-proc COM server application that exposes the functionality you require. This app could load the 64-bit filters and COM would handle the inter-process communication between your 32-bit app and the 64-bit out-of-proc COM server.

I found a way to install Filter Pack 32bits in a 64bits OS. To other file formats is similar.
Install Filter Pack 32 bits in a 32bits OS.
Copy ifilters files in directory “C:\Program Files\Common Files\Microsoft Shared\Filters” from 32 bits OS to the a directory “C:\Program Files (x86)\Common Files\Microsoft Shared\Filters” in 64bits OS.

Registry redirection on 64-bit Windows

I am running 64-bit Windows, and I want to create the registry key HKCU\Software\Classes\Wow6432Node\CLSID\{myguid}\InprocServer32 using C#.
What registry key should I tell it to write, so that it will be redirected to the above key? This should also work on 32-bit Windows.
I am compiling my app to target x86.

If you are using .net 4 you should make use of the RegistryView enumeration.
Pass RegistryView.Registry32 when you call OpenBaseKey. Use HKCU\Software\Classes\CLSID{myguid}\InprocServer32 as your key and let the redirector do the work.
If you are using an older version of .net then I am afraid you will need to p/invoke the native Win32 API.
If you happen to be targetting x86 then you don't need to do anything. The registry redirector will do the right thing and redirect your registry access to the 32 bit view of the registry. You only need to take the steps outline above from a 64 bit process.

64-bit versions of Windows emulate 32-bit functionality through the "Windows on Windows" (WoW) subsystem.
In the case of the registry, they move the 32-bit keys over to a special subkey for compatibility reasons. It will automatically redirect 32-bit registry operations to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node. More details can be found on the MSDN topic about the Registry Redirector.
You can use the RegistryView enum on RegistryKey.OpenBaseKey to open the 32-bit view explicitly and access HKCU\Software\Classes\CLSID{myguid}\InprocServer32 directly. This will automatically access the WOW64 node on 64-bit systems and the normal key on 32-bit systems.

Since you are targetting x86, simply using HKCU\Software\Classes\CLSID\{myguid}\InprocServer32 will work on all platforms.

By default your C# application is compiled using "Any CPU" (this is the default -- it means that your program will run as a x86 exe on x86 machine, and x64 on x64 machines). What you want to do is change the setting to Win32.
Now your program will always run as an x86 exe, so it will be automatically redirected by windows the WOW6432Node. When you access the HKCU\Software\Classes\CLSID{myguid}\InprocServer32 on an x64 machine you will be redirected to the desired key.

Is it OK to manually write Wow6432Node entries from VS2010 Deployment Project?

I have a .NET component written in C# that needs to register some registry values under the HKLM hive. I'm expecting this component to be installed on both x86 (32-bit) and x64 (64-bit) boxes running the appropriate flavour of Windows. On 64-bit systems, I want to make sure the component can be used by both 32- and 64-bit hosting processes. I'm stuck with using Visual Studio's deployment projects for the time being.
What I want is for my installer, when run on 64-bit systems, to put its registry entries under HKLM/Software/Blablah, so that when running in a 64-bit process, my component can find its global configuration settings. However, if my component is hosted by a 32-bit process running on the same machine, then it will read from what it thinks is the same key, but which Wow64 will translate to HKLM/Software/Wow6432Node/Blablah.
Is it OK to author my 64-bit installer so that:
it is marked as a x64 installer
it writes the entries under HKLM/Software/Blablah for the benefit of 64-bit processes
it writes exact copies of those entries under
HKLM/Software/Wow6432Node/Blablah for the benefit of 32-bit processes on the same machine.
I'm guessing that because I've marked the installer as x64, I will be forced to author another separate installer specifically for 32-bit systems, which only writes to HKLM/Software/Blablah.

The normal practise is to have both 32 bit and 64 bit install packages. On the 32 bit machine you just run the 32 bit package, on the 64 bit machine you run both.
Trying to handle all the registry and file redirection yourself is a nightmare and it's much better to install a 32 bit package on a 64 bit machine and let the system do the redirection for you. You've got to produce the 32 bit package anyway for 32 bit machines, so it's no extra work.

C# PInvoking user32.dll on a 64 bit system

Is it wrong to pinvoke user32.dll on 64 bit Windows, from a 64 bit app? I've done this successfully a number of times and never had an error, but it seems contradictory. Should I look for user64.dll instead?

The name user32.dll is misleading. It's the 64 bit version of user32.dll you're calling. The 64 bit version is located at %windir%\System32\user32.dll.
A 32-bit version is included for compatibility with 32-bit applications. It's located at %windir%\SysWOW64\user32.dll. You can inspect them using the dumpbin utility:
System32\user32.dll:
FILE HEADER VALUES
8664 machine (x64)
SysWOW64\user32.dll:
FILE HEADER VALUES
14C machine (x86)

There is no user64.dll for the exact same reason you just described, .NET program can be agnostic to CPU architecture so the same code needs to work on x86 and x64.
If you take your program to x86 platform, it will still run without any modifications.
I guess that when they named user32.dll, they didn't have those scenarios in mind.