My main stationary machine is a Windows box running Win 8.1 64-bit and Office 2013 32-bit. I developed a 32-bit DLL with functions in VS2013 which I include through Excel VBA. Functions work fine on Windows.
Then I have a Macbook Pro running Windows 8.1 64-bit and Office 2010 32-bit under Parallels 8. I do not seem to be able to work with the functions from my DLL under this Mac.
How I tried:
Copied my DLL file to a new folder C:\MyTools under Parallels.
Referenced this folder when loading the DLL in VBA. My VBA code to load a function from the DLL looks like this
Declare Function MyDLLfunction Lib "C:\MyTools\MyDLL.dll" (ByVal s As Double) As Double
I also tried double slashes \\ to no avail
The undesired result when using this function from my worksheet on Parallels is that there's an error code displayed in the cell (#VALUE).
Is it rather Excel 2010 not being compatible with DLLs in general (can't believe that), or is a matter of referencing the path with the DLL correctly on the Mac? I thought C:\MyTools\MyDLL.dll would work as this is how I see the file in the tree of Windows explorer in Parallels. Or is my Parallels 8 too outdated?
This is a shot in the dark, but it could be that your DLL is not compiled as a static library and hence there are certain dependencies which are present on your development computer (because of the Visual Studio installation) which are not there on the test computer/in the parallels environment.
Try running your DLL on Excel on an identical Windows system with no visual studio installed. If it doesn't work, the problem is likely to be as mentioned above.
Related
How could I read an Excel file with SSDT-Visual Studio 2019 under Windows Server 2016 64-bit ?
I see there are a lot of blogs describing similar issue but I'm still not able to solve my problem.
I would like to read an Excel file within my Visual Studio 2019 (SSDT Toolbox) under our Windows Server 2016 64-bit.
At first attempt (during the development) I got this error message "The requested OLE DB provider Microsoft.ACE.OLEDB.16.0 is not registered. If the 32-bit driver is not installed, run the package in 64-bit mode."
Ok, I understand VS 2019 is a 32-bit app so it, by default, tries to use 32-bit driver.
Through multiple tests I tried the actions below but none of them have solved the issue :
set the Run64BitRunTime as True
set the "Processor Architecture for AnyCPU Projects" as x64
It seems modifying those settings would apply only at RunTime level i.e at the compiled version of the package, not during the development.
When I use SQL Server Import and Export Data Wizard 64-bit (and save the SSIS Package) it do works BUT it does not help reaching 100% of my goal. The reason I use SSIS is to do complex ETL , not only reading an Excel file. Reading such file is only a small part of the process (otherwise SSIS would be quite underutilized)
The biggest constraints I currently have are:
As per company restrictions, we could not install 32-bit driver on that machine
I know Visual Studio 2022 would be 64-bit but unfortunately, at this time (October 2022), it does not have SSIS module yet
Could anyone help me to solve this?
Any helps or tips would be appreciated.
My environment:
Windows Server 2016 64-bit
SQL Server 2019 with SSIS module installed
Visual Studio 2019 with SSDT module installed
I have a 32bit VB6 Custom DLL which I was using all along until Excel 2013, Win-7. Now after moving to Excel 2016 on Win-10, the Excel file is rendered un-usable. I have done the Registration of that old DLL file on Win-10 via PowerShell (Admin mode) and it says registration successful. However, when the module in Excel executes creating the Object via CreateObject, it says ActiveX cannot create Object.
Another surprise that when I try to reference the VB6 DLL from (in Excel) Tools -> Reference, i can reference it and I can access the Class/Functions, but still when I try to execute it, it says the same error about ActiveX.
what else do I need to do in Windows-10 to have it run ?
32 bit programs can only load 32 bit dlls. 64 bit programs can only load 64 bit dlls. This is important. In COM which VB6 and Excel do, you can do non compatible bitness by forcing the wrong bitness dll into dllhost. All calls are marshalled with EXE servers. See https://learn.microsoft.com/en-us/windows/win32/com/registering-the-dll-server-for-surrogate-activation (note goggle sabotages searches for Windows).
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.
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).