Recently upgraded to a new PC with Win 10 pro, Excel 2016 coming with Office365, vs2015 community. Built a very simple vc++ dll with just one function exported in def file. The code is very simple but would still post here to give a content and make sure there's no problem there.
//also tried __declspec(dllexport) double sumCPP(double a, double b) without .def file
double __stdcall sumCPP(double a, double b)
{
return a + b;
}
'VBA
Public Declare PtrSafe Function sumCpp Lib "C:\MyTestProject\x64\Debug\DllTest.dll" (ByVal a As Double, ByVal b As Double) As Double
But a call from VBA results Run-time error '48': File not found: C:\MyTestProject\x64\Debug\DllTest.dll.
The source code of a more complicated dll project can be built to exe that runs fine, but whose dll prompted this original failure calling dll problem. Any suggestion where to look at? I've tried depends.exe with many supposedly false alarms and dumpbin /dependents but not clear how to use the result. I wonder if this is related to some vs2015 redistributable not in system PATH. I don't see any there but haven't tried to add them yet, as there seem to be too many.
Is there any other option to delegate heavy computation and TCP/IP socket besides using vc++ dll? I don't know but can consider C#, while python would be preferred. Since those dll functions are intended to be called many times in VBA, a system call to vc++ exe doesn't seem to be efficient.
Great thanks in advance!
Since the machine is new so I reset it removing all data. Then I installed Office 2016 64bit and VS Community 2015 from scratch and built the 64bit dll again. This time the error is Run-time error '453' Can't find DLL entry point. Can't find any obvious missing dependent dll by either dumpbin.exe /dependents or depends.exe.
Try change build configuration from "Debug" to "Release"
Related
I have an excel VBA macro that calls a function in a C++ DLL.
The declaration is
Public Declare PtrSafe Function XXXX Lib "xxxx.dll" (...
This has worked for years, but on some new computers, it fails with the message
“xxxx.dll not found”.
The DLL is in the current folder. I checked with CurDir() and the current folder is correct.
I have a C++ test program that calls the DLL and it succeeds so there are no missing dependencies.
If I add the folder to the PATH environment variable, it will succeed.
According to all the documentation I found, Excel will always look in the current folder for DLLs.
Any ideas would be appreciated.
Thank you.
I'm around trying to create an interoperable dll written in C # for use in Microsoft NAV 2016, for the development of a fiscal printer driver.
In my C # project I called to other functions dll (delivered by the company Bematech, in 32-bit and unmanaged).
Calls to the functions of the dll unmanaged (and tested from an .EXE) I make as follows:
[DllImport ( "BemaFi32.dll")]
public static extern int Bematech_FI_ProgramaAlicuota (Aliquot string, int ICMS_ISS);
When I try to run it from the NAV2016 I get the following error: .A call to "MyAssembly" failed with this message: You are trying to load a program with an incorrect format. Expection from HRESULT: 0x8007000B
I guess the error because the dll is not managed or 32-bit version (if that's the problem becomes more difficult because apparently there is no 64-bit version). Not how to solve the problem.
NAV cannot work with unmanaged code.
The only way is to write a wrapper dll which can be called from NAV.
Microsoft is doing the same with the Office SDK for example...
Cheers!
The problem was not the embedded dll unmanaged, was that the new dll to be 32 bit was not compatible with the client NAV, the solution was to change the 32bit client as follows:
Rename the file to Microsoft.Dynamics.Nav.Client.X64.exe Microsoft.Dynamics.Nav.Client.exe, and then a Microsoft.Dynamics.Nav.Client.X86.exe rename the file to Microsoft.Dynamics.Nav.Client. exe.
and the C / AL change in the variable declared the call to the dll
Property Value
Yes RunOnClient
I have built Xerces-c_3_1.dll from source using the Visual Studio solution provided in the download package. It works with the sample applications that are part of that package (as long as they're built with VS).
But I need to use the DLL with apps developed in C++ Builder 10 Seattle. The incompatible linkage and COFF-vs-OMF format issues (import lib) mean I need to tweak the build instructions. I believe I need to change the calling convention in the project properties from __cdecl to __stdcall, and add a DEF file to translate the exported functions for my environment.
(I believe this because I wrote and support a DLL that is used by programmers writing in many languages. I do my development in C++ Builder [familiarity with the environment], and create the release version in VS Express 2015 [massive performance improvement over Embarcadero, I'm sorry to say]. Added a DEF file for just the 32-bit version [not needed for VC++ 64-bit, just to make me nuts], and it works for everybody.)
Running TDUMP.exe on my DLL gets me output that looks like this:
EXPORT ord:0060='Edit_RunEdits'
Running tdump -ee xerces-c_3_1.dll >tdump.txt on the Xerces-c_3_1.dll built using __cdecl gets output like this:
EXPORT ord:1763='?Initialize#XMLPlatformUtils#xercesc_3_1##SAXKKKQBD0QAVPanicHandler#2#QAVMemoryManager#2##Z'
EXPORT ord:1764='?Initialize#XMLPlatformUtils#xercesc_3_1##SAXQBD0QAVPanicHandler#2#QAVMemoryManager#2##Z'
Running impdef def.txt xerces-c_3_1.dll on the __cdecl build gets output like this:
?Initialize#XMLPlatformUtils#xercesc_3_1##SAXKKKQBD0QAVPanicHandler#2#QAVMemoryManager#2##Z #1763; ?Initialize#XMLPlatformUtils#xercesc_3_1##SAXKKKQBD0QAVPanicHandler#2#QAVMemoryManager#2##Z
Repeating TDUMP and IMPDEF on the __stdcall build gets similar results.
And this is expected.
But how can I create a DEF file from this noise? I would be perfectly happy with a sample of the format to use to turn "Initialize#XMLPlatformUtils" into something the linker can match to "XMLPlatformUtils::Initialize()" in my client app.
By the way, I also used IMPLIB on both versions (__cdecl and __stdcall) to create an import library, which I added to my test project, but the linker continues to issue "unresolved external" errors for my calls to XMLPlatformUtils::Initialize and XMLPlatformUtils::Terminate. I believe that should be expected because of the name mangling.
dllmain.cpp(16): warning C4447: 'main' signature found without threading mode
l. Consider using 'int main(Platform::Array<Platform::String^>^ args)'.
Above is a warning I got from building a Windows Store App DLL project. I didn't change anything in that default dllmain.cpp file except for including my own version of pch.
The documentation for this warning (along with many VS2012 errors/warnings) is nowhere to be found on MSDN and here is the only relevant link I can find:
http://social.msdn.microsoft.com/Forums/en-US/vssetup/thread/6daa9587-fe54-4e84-a8b9-0e5c52c2f6e8/
and the op there didn't get an answer.
If anyone knows what it means and how to fix it, it would be great!
As far as I can tell, you can safely ignore the warning. The compiler cribs when it sees a Win32-style DllMain being compiled using the /ZW flag (Consume Windows Runtime Extensions). However, the function gets called as you'd normally expect.
Alternatively, you can work around the warning by compiling dllmain.cpp without /ZW. You might need to adjust the PCH settings for this to properly work. This is the path taken by the DLL (Windows Store apps) C++/CX project template in Visual Studio.
Incidentally, the reason you do not get the warning when you're trying to build a Windows Runtime Component project (which builds everything using /ZW) is that a Windows Runtime Component doesn't declare a DllMain. This is not to say that it can't; it just picks up the dummy DllMain that the CRT defines (which basically turns off per-thread initialization and reports success).
I am porting a C++ project from an old Borland compiler to VisualStudio 2008. This project uses a third party DLL that I don't have the source code for, so I am unable to recompile or modify it. The header file for the DLL defines functions along the lines of:
extern "C" {
void __stdcall Init(int a, int b);
}
However when I try to link to this DLL, VisualStudio says that it cannot find the function _Init#8. When I look at the DLL I find that the function name is _Init, and not _Init#8 (it seems that the DLL to predates Microsoft adding #8 to stdcall name mangling).
My question is: How can I call funcions in this DLL? Does VisualStudio simply not support these old DLLs, or is there a flag/setting that I'm missing. (I am aware that I could use the LoadLibrary/GetProcAddress functions to dynamically call the functions at run-time, but would prefer to not to.)
I didn't notice anything that would tell me whether you are doing 32 or 64 bit coding. MSDN has some information on how to create an import library based on a dll that you have no source for. This article is for making a 32 bit import library. CHEERS!