We have an application(built on release x86) and outlook vsto ribbon(built on release x86) and we are using Outlook redemption to communicate in between.
Redemption.RDOSession RDOObj = (Redemption.RDOSession)Activator.CreateInstance(objsession_late);
everything is working fine for 32 bit outlook. Now we have to extend our outlook vsto ribbon for 64 bit outlook so vsto compiled with release x64 and using 64 bit outlook redemption dll. here comes my issue we cant build my application on x64 as we have many 32 bit dll references. now we are trying to call outlook redemption 64 bit from our 32 bit application and getting System.BadImageFormatException(which is obvious). is there a way to resolve this please advise.
Thank you!
Yes, that is to be expected - a 32 bit process cannot load a 64 bit dll (see http://www.dimastr.com/redemption/faq.htm#ErrorCreatingRedemptionObject).
The only workaround is to move your MAPI/Redemption specific code into a separate exe and compile it in both x86 and x64. Then your main app can launch the appropriate version of that auxiliary exe based on the Outlook bitness.
Related
Just when I thought I understood Microsoft's confusing naming with regard to WIN32 and WIN64 registry and folders I read this article (Using 32-bit or 64-bit ActiveX Components on x64 Windows) and find myself still a bit confused on how to properly register 32 bit and 64 bit OCX controls on the same WIN64 computer. From the article it says that on a WIN64 system the default regsvr32 is for registering 64 bit OCX controls and to register 32 bit versions of the OCX control I should use C:\windows\syswow64\regsvr32.exe. The thing is I've been registering my WIN32 OCX control using the default regsvr32.exe (in C:\windows\system32) and it seems to have been working fine when I run my 32 bit app which uses the 32 bit OCX. I have the following questions:
Q1 How has registering WIN32 OCX with default regsvr32 been working given what I read in the article.
Q2 I want to register both the WIN32 and WIN64 versions of the OCX control on a single computer. From the article it seems like I should use the two different versions of regsvr32.exe from syswow64 and system32 for WIN32 and WIN64 versions respectively. Is this correct?
Q3 Can the GUID for the OCX be the same for both the WIN32 and WIN64 versions? I'm thinking it can be the same since a different portion of the registry is used to register for each of these architectures. Correct?
Q4 Where do I look in the registry to confirm that both 64 and 32 bit versions of the OCX have been registered to confirm that registering the 2nd one didn't overwrite the first one?
Per suggestion in comment by Andrew here is my comments as an answer.
A1 & A2 Well since no one has replied to this I'll add what I've learned since posting. It seems the article I referenced is misleading in describing how to run 32 and 64 bit regsvr32.exe. From my own testing it seems that the default 64 bit regsvr32.exe can be used to register both 32bit and 64bit OCX controls. It seems regsvr32 (the 64 bit version at least) looks at the target OCX or DLL file and determines if it is 32 or 64 bit and installs it in the appropriate registry. There doesn't seem to be any need to use the 32 bit version of regsvr32 on 64bit windows.
A3 Yes both 64 and 32 bit versions can be registered which use the same GUID.
A4 For 32bit OCX in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID area of the registry and for 64 bit its in
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID
I just added the '64 bits platform' to my project and my Delphi (XE7) keeps generating a huge RSM file (which increases the compilation time). According to the Help this should not happen if the 'Include remote debug symbols' option is disabled.
And in my case it is disabled.
There is something else to be disabled?
from http://embarcadero.newsgroups.archived.at/public.delphi.ide/201203/12030416462.html
Delphi XE2 generates RSM files that are several MB in size. As I
understand it, these files are for remote debugging. Is there a way
to turn off the generation of these files?
Yes. In the Project Options look on the page "Delphi Compiler\Linking"
for "Include remote debug symbols" and turn it off if you do Win32
debugging. Note it is necessary for Win64 debugging.
and continuing on http://www.devsuperpage.com/search/Articles.aspx?G=2&ArtID=20168
The IDE is 32-bit, because that's the only way it can work on both 32
and 64 bit versions of Windows. (Win64 can run 32 bit apps, but Win32
can't run 64 bit apps.) That's why the remote debugger is used for 64
bit and cross-platform apps.
Jeff Overcash from TeamB
Is the reason that Delphi XE2 is not itself really 64-bit?
Sure, then it can't be run on 32 bit OS's. All third party components
won't work at all until a 64 bit version of it exists (a 64 bit IDE
would not be able to load a 32 bit bpl), this would be a major reason
for people not to upgrade too. Supporting both a 32 bit and 64 bit
IDE doubles the testing time for little to no benefit.
Situation:
I developed a DelphiXE5 ISAPI Webbroker application on a VMWare workstation under WIndows 7 Pro 64Bit. Testing on that platform with the code compiled as 32bit (default for DelphiXE5) was successful. The program consacts Stamps.com via HTTPS and uses the Stamps.com SOAP web application to purchase postage and create a mailing label with a valid postage stamp (indicium).
The mailing label is created as a PDF on a Stamps server and they send me back a URL which I then use to fetch the PDF and save it in my local SQL Server database. This fetch is done using INDY 10.6.0.5040 (per Remy at Indy). As part of that fetch, the INDY ssl component has to load and use the OpenSSL libraries. These load OK in the test environment.
I then moved the program (compiled as 32bit) to the Windows 64bit 2003 R2 server. This server is a virtual server running under VMWare. I am sure that the actual hardware is truly 64 bit. The OpenSSL libraries will not load on that server. I have tried the most current 32 bit libraries and the most current 64 bit libraries. Same result ... not loading. I tried the ones that load successfully in test .. they failed. Using the Indy WhichFailedToLoad() function shows "failed to load libeay32.dll". Funny thing is , I get the same message with the 64bit libraries. The libraries, even though 32 vs 64 bit, have the same name, so i get the same message. Now, my specific questions are ....
could there be a default area that the libraries load from and my placing them in the same directory as my program dll is not changing anything at all ?? Indy is going the default first and if they exist, that's the ones it is using. If so, does anyone know where that might be. I have tried to trace through the INDY code to see what was hapening but it jumps into assembler and I'm not a ms assembler programmer. I know IBM mainframe assembler in my sleep but MS seems uside down and backwards to me :-)
For Delphi experts out there.... SHould the program really be compiled as a 64 bit application and put in production and then use the 64bit libraries? In the test environment I'm running on 64bit hardware, 64bit host, 64bit guest on which the 32bit compile takes place. The 32 bit libraries work there and it seems that it should work in production on W2003 Server as that is identitical .. except for the OS version.
Could it be permissions problem with IIS 8.5 that wont let my dll read or load the OpenSSL libraries ? If so, any hints as to what ?
I have the DLL in the scripts directory along with libraries.
Who ever figures this out can get a job as my backup :-) ... really !
If your program is 32bit, the dll it uses have to be compiled in 32bit.
As for the location of the OpenSSL dlls, in my case, on a Win2012 R2 server, I put them in C:\Windows\SysWow64\inetsrv.
We have an Delphi application that has a built in com object. When compiled in Delphi XE3 (Windows 8) we can't reference it from Visual Studio C#. However, an older version that was compiled in Delphi 2010 (Windows 7) works as expected.
The com object registers without errors and i can access it by using VBA script in Excel. Has anyone come accross something like this?
The most likely explanation is a bitness mismatch. I'm assuming that the COM server is 32 bit since you have been compiling it in Delphi 2010.
Suppose that your COM server is an in-proc server. Then I guess that your failing host is a 64 bit application. If so then you need to make the bitness match. Most probably by switching your host to be 32 bit by targeting x86.
If the COM server is out-of-proc then the issue is with registration rather than executable bitness matching. It will be registered in the 32 bit registry view, but your 64 bit host is looking in the 64 bit view. This would explain why your 32 bit Excel VBA code can find it. You need to register the server in both 32 and 64 bit registry views. Or switch the host to 32 bit.
A number of delphi applications that I work with use an activex chartfx control. I realize that the company softwarefx stopped supporting delphi a while ago but we are transitioning to 64 bit builds and this component is our main obstacle. We could convert all our charts to TeeCharts if necessary but this would be a lot of changes.
I have gotten the 32 bit chartfx component to install and compile in xe2 but am unsure of the next step. Support did provide me with 64 bit dlls.
So I guess I have 3 questions:
has anyone sucessfully moved chartfx to a 64 bit delphi environment or
could you direct me to instructions on creating a component that is 32 bit at design time but can be 32 bit or 64 bit for compile?
is there a better way to do this?
edit: uploaded chartfx62 client server delphi code to http://www.filefactory.com/file/ce61229/n/Cfx62ClientServer_TLB.pas
You need to get the 64 bit ActiveX DLLs to go with your 64 bit runtime. Designtime Delphi is still always 32 bit.
If ChartFX doesn't supply 64 bit version you are stuck. Having looked on the website it seems that the vendor does not yet supply a 64 bit ChartFX ActiveX and is soliciting feedback as to how much demand there is for it.
I would recommend transitioning to TeeChart which is native Delphi code and has a very strong tradition on Delphi. You can be confident of future support for other platforms as and when they become available.