One of our users has an Excel VBA project that references Microsoft Windows Common Controls 6.0. The corresponding MSCOMCTL.OCX file is no longer in our image, and so of course the project won't run due to a missing reference.
Rather than installing Microsoft Visual Basic 6.0 Common Controls on our Windows 7 64-bit systems with Office 2016 64-bit, is there something different that the user can reference in their project that is more modern and supported?
Side question: If we do install it, will it even be able to work, with 64-bit Excel calling a 32-bit OCX?
Answer: I tried on a 64-bit Office installation, and the answer is No. You can install it, register it, and reference it, but you can't actually use any of the UI controls from it. They simply don't appear in the list.
Related
I have an Excel add-in on a VM that uses the "Microsoft TreeView Control, version 6.0" as a part of Microsoft Windows Common Controls 6.0 (SP6), located at C:\Windows\system32\MSCOMCTL.ocx. The properties window on forms that use the TreeView control show the control as [TreeView control name] TreeView3. Everything works great, and I don't receive any errors.
I also have copies of the working VM with the same Excel add-in, but I receive a Microsoft Forms error that reads "Could not load an object because it is not available on this machine." when I open Excel and the add-in loads.
I am able to re-create the forms, using the same "Microsoft TreeView Control, version 6.0" (same file location and reference), but this TreeView control appears as [TreeView control name] TreeView2 and the error no longer appears.
Instead of re-creating all the forms that use the TreeView2 control, how can I prevent the issue from happening in the first place? The machines are obviously not exact copies. With the exception of .NET v4 installed on the working machine, I don't know what has changed that corrected the issue. It is my understanding that the Windows Common Controls should not be impacted by simply installing .NET v4 on the machines that have the error.
EDIT:
Installed the following and it did not work:
https://www.microsoft.com/en-us/download/details.aspx?id=10019
Also took a shot and installed .NET v4, and still no luck.
Specifications on working machine:
Windows 7 Professional SP1
Excel 2010, Version: 14.0.7162.5000 (32-bit)
Computer\HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP and it has v2.0.50727, v3.0, v3.5, and v4
Specifications on machines with the issue:
Windows 7 Professional SP1
Excel 2010, Version: 14.0.7162.5000 (32-bit)
Computer\HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP and it has v2.0.50727, v3.0, v3.5
EDIT #2: failed to mention that the machine with the issue is a 64-bit OS
Information from Registry for versions of TreeView controls on Working machine and Non-Working machine
Working Machine
Computer\HKEY_CLASSES_ROOT\MSComctlLib.TreeCtrl\CurVer - MSComctlLib.TreeCtrl.2
Computer\HKEY_CLASSES_ROOT\CLSID{C74190B6-8589-11D1-B16A-00C0F0283628}\Version - 2.1
Windows 7 Professional SP1 32-bit
Non-Working Machine
Computer\HKEY_CLASSES_ROOT\MSComctlLib.TreeCtrl\CurVer - MSComctlLib.TreeCtrl.2
Computer\HKEY_CLASSES_ROOT\Wow6432Node\CLSID{C74190B6-8589-11D1-B16A-00C0F0283628}\Version - 2.0
Windows 7 Professional SP1 64-bit
I have a VB6 Outlook add-in. This is tested and working on a Windows 7 64bit machine, with 32bit OFFICE installed.
On another PC, Windows 7 64bit, 32bit OUTLOOK install, the add-in does not load. It is not listed in the list of COM add-ins, and when I try to add it to that list manually, it does not appear!
I assume that there is some dependancy with some office DLLs causing the issue but I don't know how to troubleshoot to find out where the issue lies.
Can anyone give me any tips??
Thanks in advance!
I got exactly the same problem until I realized the problem was coming from C:\Program Files (x86)\Common Files\DESIGNER\MSADDNDR.DLL, that is brought by Office 2013 Pro with a file modified in 2010, and not with the family version. Check out http://blogs.msdn.com/b/vsod/archive/2012/11/21/vb6-based-add-ins-may-fail-to-work-on-office-2013.aspx and http://support.microsoft.com/kb/2792179 that mention this issue. Another important thing to note that that the Family edition looks to be a ClickToRun version (simili AppV virtualized application and Professional version is a fully installed version).
I developed a 64-bit Addin.
For testing I added it on a laptop (64-bit machine with 64-Windows7 Enterprise and 64-bit Office 2010) [other than the one i developed the Addin on], its works fines i can call n use its functions. but when i add the same addin on a desktop machine (64-bit machine with 64-Windows7 Enterprise and 64-bit Office 2010), its functions are not available and no error message displayed as well. But when i re-launch Microsoft Excel 2010 a message appears.
Message text : "The file you are trying to open, 'MyAddin.xll', is in a different format than specified by the file extension. Verify that the file is not corrupted and is in from a trusted source before opening the file. Do you want to open the file now?"
As per the message text i verified that the location for xll is included in "trusted location". Yet the issue not resolved.
Whats your opnion in this regard,
Thanks & Regards,
Maverick.
Check that you have compiled it Release and not Debug (if you've done the latter it will only work on machines with the debug versions of included DLLs, which usually means machines with Visual Studio installed).
Does a System.Runtime.InteropServices.COMException of 0x80040154 always mean that the class isn't registered? I'm getting a COMException which says "Retrieving the COM class factory for component with CLSID {29131539-2EED-1069-BF5D-00DD011186B7} failed due to the following error: 80040154." It's trying to load Interop.Domino.dll which is a reference I got from the COM tab of Add Reference called "Lotus Domino Objects" which points to domobj.tlb in the Notes program folder.
I wrote the code years ago - it's the only thing I've ever done with interop and it's fair to say that I never really got to grips with it.
I'm seeing this error again after moving the code to a 2008 R2 server (so it's x64). It was written on XP and run on 2003 (both x86). In order to diagnose the problem, I built a Win7 x86 (because there's no R2 x86) box and it worked. I also built a 2003 x64 box and it fails with the same error, so it looks like it's caused by moving to x64 architecture. Is there something I should do when doing interop to get x86 COM DLLs to work on x64 machines?
I had the same problem trying to build and run a .NET application on Windows 7 x64 that called interop.domino.dll, which is 32 bit only.
To resolve, I recompiled the .NET application to run specifically as x86 when run on x64 operating systems.
I was using Visual Studio 2010 Express Edition which is trickier to target specifically for x86 platforms than the paid for versions.
The solution was:
Click TOOLS > OPTIONS > PROJECTS AND SOLUTIONS
Check the box "Show advanced build configurations" and click OK
Click TOOLS > SETTINGS > check EXPERT SETTINGS to see the build configuration manager
Click BUILD > CONFIGURATION MANAGER select the platform dropdown to X86 and click CLOSE
Now rebuild the project
Pay attention to register of 32-bit components using the correct register (C:\Windows\SysWOW64\regsvr32.exe).
If you have already registered up with the 64-bit version, unregister each dll with the same version.
More help you find here Team is Going from XP32 to XP64 for .NET Development - Any Gotchas?
Good luck
There's an IBM technote that indicates that the Domino COM classes are not supported on a 64-bit OS. See https://www-304.ibm.com/support/docview.wss?uid=swg21454291 So it seems like even by compiling the code to run as x86 (as per mpownie's answer), you're still taking some chances.
Have an SSIS 2008 package that runs just fine on my local dev machine with Office 2007 installed. It has a script task with interop.excel as a reference. (I'm reformatting some excel sheets with it)
So everything works like a champ until I install and run it on my test SQL 2008 (Server 2008 64bit) server. I install to SSIS, execute it via a SQL Server Job, it runs though most of the steps but then throws an exception when it gets to the script task that needs the excel interop assembly.
I've installed the 2007 PIA and have execution marked as 32bit as well. At this point I'm just kind of lost. Any help is appreciated.
This script task - Is it a .NET script task or a 32-bit script task?
I'm guessing from the interop.excel reference, that its a .NET script task calling out to an old 32-bit library? Can you confirm?
If there is a 32-bit component that you are running on your Win64 environment then you need to be careful about what you are using to register it. By default, regsvr32 is the 64-bit version, so you need to use the regsvr32.exe under c:\windows\systemWOW64 (or something similar). This will ensure the dll is registered in the 32-bit hive of the registry, and available to the WOW (windows-on-windows) emulation environment.
SpreadsheetGear for .NET is an Excel compatible spreadsheet component for 32 bit and 64 bit .NET, and has an API which is similar to Excel's COM API.
You can see some live ASP.NET samples here and download the free trial here.
Disclaimer: I own SpreadsheetGear LLC
I installed Office 2007 on the server I was using. That fixed one problem. Then I discovered another problem that was alleviated by this SO Link