I understand that I cannot load a 32 bit dll in a 64 bit process. I have a 32 bit dll (VB6 component), with no source code, that is loaded in an Excel automation macro. What are my options?
32-bit add-ins are not supported on 64-bit. Microsoft recommends to use the 32-bit version of Office unless you run into the memory limitations of a 32-bit process which is only likely to happen if you need to deal with extremely large spreadsheets:
The recommendations for which edition of Office 2010 to install are as follows:
If users in your organization depend on existing extensions to Office, such as ActiveX controls, third-party add-ins, in-house solutions built on previous versions of Office, or 32-bit versions of programs that interface directly with Office, we recommend that you install 32-bit Office 2010 (the default installation) on computers that are running both 32-bit and 64-bit supported Windows operating systems.
If some users in your organization are Excel expert users who work with Excel spreadsheets that are larger than 2 gigabytes (GB), they can install the 64-bit edition of Office 2010. In addition, if you have in-house solution developers, we recommend that those developers have access to the 64-bit edition of Office 2010 so that they can test and update your in-house solutions on the 64-bit edition of Office 2010.
If you need to go with the 64-bit version because of the memory limitations you have the following options:
If you have the source code, you can generate a 64-bit version yourself,
You can contact the vendor for an updated version,
You can search for an alternative solution.
There actually is a fourth option which is not mentioned in this article by Microsoft: You can create a 32-bit out-of-process COM server which serves as a proxy between your 64-bit macros and the legacy 32-bit COM components or create a COM+ application. A sample is provided here:
Accessing 32-bit DLLs from 64-bit code
Related
Here is what I have:
Problem: Trying to connect two different 64-bit applications:
Microsoft Access 64-bit
QuickBooks Entrprise 21.0 (I'm not sure if it is actually 32-bit or 64-bit)
Using:
Visual Studio 2022 64-bit edition
VB.NET
64-bit version of QBFC15 library for QuickBooks
My thought is that when you use a 64-bit API, it would connect to a 64-bit application. I am most likely incorrect.
When I connect to MS Access in the debug 64-bit mode, it connects fine. The Intuit developer Network says you need to publish applications in the 32-bit mode. I have always used the 32-bit mode for publishing QuickBooks applications because they were 32-bit programs and, well, frankly, 64-bit applications hadn't come out yet (no old person jokes here). Anyway, I was really excited to see that the 64-bit version of a QBFC library came out (QBFC15) and they offer both 32-bit and 64-bit. So I downloaded the 64-bit version (which they recommend on their site https:\\developer.intuit.com>
So I'm thinking, hey, it's a 64-bit SDK! Yeah! So now I have this project that tells me I need to connect a 64-bit Access application to QuickBooks. When I debug, my new application connects just fine to MS Access in the 64-bit mode! Yeah! But the 64-bit Intuit SDK needs to be published in the 32-bit mode!!!! I'm confused. I know that they have put the cart before the horse and I know that they must still be running QuickBooks Enterprise in the 32-bit mode but come on. Putting out the SDK before the commercial product comes out to use it one? (I'm done whining now...got to get it out somehow!).
So how am I to connect my application to both "64-bit" programs when one errors in the 32-bit mode and the other errors in the 64-bit mode?
The programming isn't the issue, but this scenario seems really problematic. Do I tell the customer they need to downgrade their Microsoft Office to the 32-bit mode version? That would be an easy answer I guess, but it sure makes me look bad. Any other suggestions out there that could help me in this would be much appreciated.
If you running desktop edition of QuickBooks, then if you are running a x32 bit version of QuickBooks?
Then that means automation and working with the desktop edition means your software ALL MUST remain x32.
Only in 2022, have they rather recent upgraded and offer a x64 bit verison.
So, you have to check which desktop version of QuickBooks you are running. (most up to rather recent have been x32 bits - for a VERY long time).
So, what determines what QBFC library, what version of Access, and quite much vb.net?
You must continue to force your vb.net projects to run as x86, and NOT use "any" CPU and not use x64.
So, what will determine what all of your code is to run as?
It will be the desktop edition of QB that determines this.
It is of ZERO use to adopt office x64, access x64, or run your vb.net software, and the QBFC sdk and library as x64 bits if QuickBooks remains as x32.
(you using the wrong bit size and architecture here).
so, you have to be 100%, and in fact 200% sure
now, if QBFC is hitting the server database for QuickBooks, then that can be x64 bits but if you using the QB sdk and QBFC? Then that all must remain x32 bits until such time you upgrade the desktop edition of QuickBooks.
So, you have to REALLY but REALLY find out if in fact if you are running x32 QuickBooks for desktop, or x64 for desktop.
The version of QuickBooks and what version you you THEN much choose of QBFC library, vb.net, Access/office then again will have to match the bit size of QuickBooks desktop.
So from everything else from down to Access to vb.net to QBFC then all again much match the version of QuickBooks for desktop you have installed.
Now, if vb.net, Access you use is NOT to interface via the QBFC .dll and SDK? Then you don't care. But, inter process communication based on so called "windows COM objects"? And say upgrading from office x32, and the associated software systems you have? You can't just out of the blue decide to jump to office x64 without say your company and IT department not knowing the difference between x32 bit software, and that of x64 bit software.
Hint: 8 bit Apple II computer has a different architecture then a 16 bit IBM PC. And going from 16 bits to x32 bits? Again, a huge and large jump.
And from x32 bit software to x64 bit software? again a huge jump.
So, while windows can happy run x32 bit software, and it been a x64 bit OS by default for 10+ years?
Well, software packages running as x32 bits, and them interfacing to x64 bit software is a whole different matter. Such software has to remain the same bit size - and you can't have different bit size process on windows such as x32 bit COM objects (ole, COM, ActiveX = same technology stack).
So keep this basic knowledge and hallmark and pillar in our industry - different bit size software systems can't talk to each other via inter-op, or so called COM object automation.
Our servers are upgrading to Windows 10 64-bit (which is also using Office 64-bit products) and I noticed that in this environment, the old Outlook Redemption code I run in my MS Access VBA applications no longer work due to Access being unable to load the usual dll files (Redemption.dll, StrStorage.dll, dynapdf.dll). Is there a way to get this to work in 64-bit Office?
You will need x64 bit version of the app + dll's used. So if you using say tree-view, there not a x64 bit version. Same goes for any "add in", and that includes Redemption. You course of action is to find a x64 bit alternative, or hope that a x64 bit version of Redemption is released. Same goes for activeX calendar control, or any other add-in, or activeX control(s) you use. You have to ensure that x64 bit versions of such controls or add-ins are available before you can really adopt office x64 bit version.
Make sure the bitness of Access (where your code is running) matches the bitness of Outlook / MAPI system.
Since Redemption (unlike OOM) is an in-proc COM library, it bitness must match the bitness of your code (COM system takes care of that). But since Redemption loads the MAPI system in-proc, the bitness of the MAPI system must match the bitness of the host.
See http://www.dimastr.com/redemption/faq.htm#ErrorCreatingRedemptionObject for more details.
I am struggling to apply an existing 32bit COM addin to 64bit Microsoft Word 2010.
To make the addin visible to Word, I have used the dllsurrogate-method, as it described here.
The problem is that now addin caused some strange exception when tries to add its toolbar and menu to office's. I cannot figure out, what it is, it seems, that the command bar reference became not valid in unpredicable moments.
Can anyone explain this?
Note, that everething is fine when I use the same addin under 32bit Microsoft Word 2010 and more old versions of Ms Office.
32-bit add-ins are not supported on 64-bit. Microsoft recommends to use the 32-bit version of Office unless you run into the memory limitations of a 32-bit process which is only likely to happen if you need to deal with extremely large spreadsheets:
The recommendations for which edition of Office 2010 to install are as follows:
If users in your organization depend on existing extensions to Office, such as ActiveX controls, third-party add-ins, in-house solutions built on previous versions of Office, or 32-bit versions of programs that interface directly with Office, we recommend that you install 32-bit Office 2010 (the default installation) on computers that are running both 32-bit and 64-bit supported Windows operating systems.
If some users in your organization are Excel expert users who work with Excel spreadsheets that are larger than 2 gigabytes (GB), they can install the 64-bit edition of Office 2010. In addition, if you have in-house solution developers, we recommend that those developers have access to the 64-bit edition of Office 2010 so that they can test and update your in-house solutions on the 64-bit edition of Office 2010.
If you need to go with the 64-bit version because of the memory limitations you have the following options:
If you have the source code, you can generate a 64-bit version yourself,
You can contact the vendor for an updated version,
You can search for an alternative solution.
I am bit confused as on this..
Which version of Share Point designer (32 or 64bit) do I need to use to work on SP 2010.
When I try to download the 64 bit , I see a message as "32 bit is recomended for most users ..".
I have installed SP 2010 on win 2008 R2 in virtual box. Is it mandatory for me to install Vs 2010 on same machine to develop web parts ...?? Can I install Vs 2010 in a different machine ..?? Which version of VS 2010(Express, Prof, Prem or Ult) is required ..??
Sharepoint 2010 can be installed on client machines with Windows 7 or Vista.
It is required for Sharepoint 2010 products that you are running x64 version of OS.
The development tools like VS and Sharepoint designer can be either 32bit or 64bit.
Microsoft recommends 32-bit for all the Office products, including SharePoint Designer included. I believe it's mostly to do with compatibility with other programs.
"The 32-bit version of Office 2010 is the recommended option for most people, because it prevents potential compatibility issues with other 32-bit applications, specifically third-party add-ins that are available only for 32-bit operating systems."
Taken from here: http://office.microsoft.com/en-us/sharepoint-designer-help/choose-the-32-bit-or-64-bit-version-of-microsoft-office-HA010369476.aspx
Which version of Share Point designer (32 or 64bit) do I need to use to work on SP 2010?
You can use both the 32-bit or the 64-bit version. But, it is recommended that you install the 32-bit version because the Office 2010 32-bit version is recommended. If you install the SharePoint Designer 2010 64-bit version than you cannot install the 32-bit version of Office 2010.
I have installed SP 2010 on win 2008 R2 in virtual box. Is it mandatory for me to install Vs 2010 on same machine to develop web parts ...?? Can I install Vs 2010 in a different machine ..?? Which version of VS 2010(Express, Prof, Prem or Ult) is required ..??
I have also installed SP 2010 on Win 2008 R2 in VBox. The SP installation is a standalone installation. I have also installed VS 2010 on the same VM. But, you could separate out the SP and VS 2010 installation on multiple VMs. The downside is you will need to have both VMs running at the same time (at least during your deployment to SP). You will need at least the professional edition of VS 2010.
Is there a way to compile a VB6 component into 64 bits?
My feeling is that the answer is "no", but I would like to confirm this.
Please, if you can, paste a link to an authorative source that would confirm.
No. I hope this counts as authoritative.
64-Bit Windows
Visual Basic 6.0
runtime files are 32-bit. These files
ship in 64-bit Windows Operating
Systems referenced in the table below.
32-bit VB6 applications and components
are supported in the WOW emulation
environment only. 32-bit components
must also be hosted in 32-bit
application processes.
The Visual Basic 6.0 IDE has never
been offered in a native 64-bit
version, nor has the 32-bit IDE been
supported on 64-bit Windows. VB6
development on 64-bit Windows is not
and will not be supported.
No it cannot (well Microsoft has not released a compiler to compile it for a 64-bit environment), but this does not mean that it won't run on a 64-bit system. To run it in conjunction with IIS, you'll need to install the 32-bit version of IIS.