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).
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 had a working LabVIEW Program on my PC until my LabVIEW license timed out.
Before it expired, I created an executable file and a runtime support.
Everything just works out nicely as before, except the part, where I save my data into an Excel file. (Worked in the 'normal' developers version.)
On the bottom picture, the procedure of how I save the data is shown.
I suggest there is a communication error between LabVIEW and Excel. Since I cannot develop my LabVIEW program any further (no license), it would be nice, if you have a fix on the Excel side.
Thanks a lot in advance!
My Excel specifications:
Microsoft Office Excel 2003 (11.8404.8405) SP3
My Windows specifications:
Microsoft Windows XP Professional
Version 5.1.2600 Service Pack 3 Build 2600
32bit
My LabView specifications:
LabVIEW Version 8.6
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
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.
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).