we are preparing for using windows x64 for our installations,but we are facing a problem about storing application settings(user and machines). Currently we store them in windows registry - HKLM and HKCU hives.
The problem is that there will possibly be both x86 apps and x64 apps,and x86 apps cannot access 64 bit registry. We could store everything in 32-bit registry (visible as wow64 in x64 app). Or we can store settings in a file -sqlite or sql server compact database to avoid concurrency hazards.
Do you have any advice? If yes,what is it? :)
32-bit apps can access the 64-bit registry. See the REGSAM argument of APIs like RegOpenKeyEx
Also note that only certain areas of the registry are partitioned so you may not have to do anything, depending on where things are stored.
As for whether you should use the registry or move to something completely different, that's quite an open-ended question. If you're happy with the registry other than this issue with 64-bit then I'd say stick with it and just use the REGSAM arguments to explicitly point to the 64-bit registry if and as required. (Or vice versa, make your 64-bit apps look in the 32-bit registry.)
Related
I've installed Firebird 3.0.3 Classic Server 32-bit on a newly setup Windows Server 2016 (32-bit because I have to use a legacy UDF dll that's only available in 32-bit). Except for the 64-bit ODBC connection, all connections work fine from client machines (32-bit ODBC connection, FlameRobin). But when I try to access the database through the 64-bit ODBC DSN, I get the error "your username and password are not defined".
My client machine in this case is a Windows Server 2012 R2. I've done the following steps:
install the 32-bit Firebird Client libraries (version 3.0.3)
install the 64-bit Firebird Client libraries (version 3.0.3)
install the 32-bit ODBC driver (version 2.0.5.156)
install the 64-bit ODBC driver (version 2.0.5.156)
open the 32-bit Windows ODBC administration console and create the DSN - connection test OK
Screenshot: https://postimg.cc/WDrJQryH
open the 64-bit Windows ODBC administration console and create the DSN - connection error!
Screenshot: https://postimg.cc/5XDC7psz
I'm sure I haven't missspelled the password. What could I have missed? Thanks a lot!
In general problems like this (when you have two almost identical applications and only one of them working) are often diagnosed by comparing their behavior and looking for differences, then trying to change computer or application setting to eliminate suspicious and unneeded differences unless both program work. A useful tool for it would be for example SysInternals Process Monitor, which can be set to record files I/O tracks (also registry and other things), which can give a valuable insight into program implementation and its failure. In this particular case when u press "test connection" buttons in ODBC32 and ODBC64 windows the track of files and registry accesses would probably highlight where things start go wrong for 64-bits application in contrast with the 32-bits one.
If to skip systematic diagnostic for a while and try mere guessing, then Mark suggests that the 64-bit app fails to locate the proper fbclient.dll (where proper might mean many things: FB version, 32/64-bitness, textual configuration files and what not).
Seeing your ODBC setup windows have an explicit fields "Client" with "Browse" button I make a guesstimation that ODBC tries to auto-locate the client library and for some reason locates some unlucky one.
Then I suggest you to try to set that "Client" field to precisely the fbclient.dll file that the Firebird engine itself uses, and if you did not changed default installation settings it would be something like something like "c:\Program Files\Firebird\Firebird_3_0\bin\fbclient.dll"
I have a analysis server database that runs Windows Server 2008 64 bits. And users reach cubes by msmdpump.dll. There is any problem before used FileMaker on same server. I could not analysis server database. I searched some documents that say I must change the application pool to 32 bit enabled. I changed OLAP web.config and added ISAPI filter. Also I read that I should use 32 bit msmdpump.dll but I run IIS 64 bit and how could you find 32 bit dll. Now I can not reached in any way. Could you help me what steps need to follow?
To install and configure OLAP Pump for IIS x64 connecting to an SSAS x64 instance, you use the msmdpump.dll of your x64 SSAS installation dir. To access an SSAS x86 instance, you use the msmdpump.dll of your x86 SSAS installation dir. The second variant requires you to enable 32 bit on your application pool.
A very nice guide of how to set up SSAS access via IIS can be found here:
Microsoft - Configure HTTP Access to SSAS via IIS
Many thanks and best regards
I have a web service which loads a 32-bit COM component. I am running this web service with IIS server in my local machine.
When I load the the test page from Visual Studio it succeeds, on the other hand, while loading it using IIS, it display following error
Retrieving the COM class factory for component XXX failed due to the following error: 80070005.
I tried changing the webservice's platform to x86 from Any CPU but that dint help. I am running this on Windows Server 2008 R2 - 64 bit.
I had to enable the 32-bit Applications from the Application Pools settings.
Check permissions on that COM. It may be that when you're running tests from VS, you're running as you (admin), while the user running the website's app-pool is totally different. That user needs to be added read+execute (or, activate, whatever) permissions for "local".
Maybe also see this: Retrieving the COM class factory for component error while generating word document
Sarat, this cannot be right. The "Enable 32-bit Applications" under Application Pools Defaults is not for running 32-bit applications or to solve your problem. It is there to enforce running 32-bit applications UNDER 32-bit processes only, which is not necessary in this case. Most 32-bit applications run fine on 64-bit processes. That's why you can run MS Office 2010 (which is still a 32-bit application) on Windows 7 64-bit machines.
You must have other settings tried and true after nearly a full year answering the original problem.
May you help me, My ASP.NET application can't import excel file when migrating this application that run in Win Server 2003 32-bit to the Win server 2008 64-bit environment.
How to fix this bug? because in Win Server 2003 32-bit, it runs properly.
the error report that appear is:
*System.Runtime.InteropServices.COMException (0x800A03EC): Exception from HRESULT: 0x800A03EC at Microsoft.Office.Interop.Excel.Workbooks.Open(String Filename, Object UpdateLinks, Object ReadOnly, Object Format, Object Password, Object WriteResPassword, Object IgnoreReadOnlyRecommended, Object Origin, Object Delimiter, Object Editable, Object Notify, Object Converter, Object AddToMru, Object Local, Object CorruptLoad) at Admin_ImportRisk.CreateTempTable() in C:\inetpub\wwwroot\ERMApproval\Administrator\ImportRisk.aspx.vb:line 66.*
The code in line 66 of my application is:
oBooks.Open(Server.MapPath("~/App_Data/Risk.xls"))
I have tried several scenarios:
Added Network Service user to the Microsoft Excel Application in DCOM configuration and set the identity of Application pool that in used to be same.
Added all many kind of user to the Microsoft Excel Application and My computer in security of DCOM configuration. And I have added many kind of user too in the application's folder.
Used corflags.exe to force 32-bit application to run in 64-bit environment
Used regsvr32.exe to register a Microsoft.Office.Interop.Excel.dll file to the windows 32-bit component services.
Used rundll32.exe to run the 32-bit Microsoft.Office.Interop.Excel.dll file in the 32-bit environment
But the result is still the same.
It will be a big honour if you can help me^^.
Best regards,
-imanuel-
The simple answer is to compile your project to target x86 only. This is a setting in the project settings. So the .net framework will only generate a 32 bit application at runtime, rather than defaulting to 64 bit. This is no different from setting corflags, however if you have multiple assemblies you ahve to make sure it's done for all of them. The application itself must target only 32 bit.
You're using a COM component that is 32 bit, and you can't do that in a 64 bit application, so force it to be 32 bit.
You can also force IIS to run it in the 32 bit context as documented here:
http://lostechies.com/gabrielschenker/2009/10/21/force-net-application-to-run-in-32bit-process-on-64bit-os/
Also, make sure the 64 bit version of Excel is not installed on the server, but rather the 32 bit version.
We have 64-bit Windows server and we need to explicitly enable the 32-bit mode in the Application Pool used by our web site, because the MS Jet Engine Data Provider used to import data from Excel does not run.
I am not sure, if we enable the 32-bit mode will we still get the advantage of 64-bit Server?
In IIS 7.x, there is a Advanced Settings property of the application pool called "Enable 32-bit Applications". If you run the application as a 32-bit applications it should be able to use 4 GB but obviously no more. So, in that respect, it can take advantage of running on a 64-bit server. On a 32-bit server (without special switches) it would only be able to use the 2GB of address space allocated to applications (the other 2 GB is presumed to be used by the OS).
ACE driver 64 bit is now available as a replacement of Jet driver. So you can use it instead,
http://blogs.msdn.com/b/psssql/archive/2010/01/21/how-to-get-a-x64-version-of-jet.aspx
(Read the last few paragraphs.)