I want to use a function of my Encryption.dll in my VBScript.
If I try to register the dll with regsvr32 /i Encryption.dll I get the error that the dll is loaded, but he can't register the file because there is no DllRegistryServer-Entrypoint.
So I tried another way as I read in a forum:
Set yourClass = CreateObject("Encryption.Hashing")
There I'm getting a ActiveX error.
Anymore ideas of what I can do?
Sounds like maybe the DLL was compiled improperly? Do you have the source? If not, try something like Telerik's JustDecompile and see if it can decompile it. This is not the end all be all kind of test but if it's a .NET dll, you should be able to decompile it. If it's a native DLL, there should be an error.
Without knowing that, there's several reasons you could be having problems.
Try creating a wrapper that exports the functions you need; test it in VS and then build it and try installing it again. Oh, one more thing. Native Libs have a .lib file that usually comes with the DLL if it's meant to be linked to for invoking purposes. That .lib and it's corresponding header files will be what you need to write a wrapper. Cheers.
Related
I want to use this project face_eye_detection.zip.
When I run it I get an error 'library failed to load',
So I changed the dll link
but the problem remains the same, I even change the dll link and it doesn't work.
Where exactly is the problem? In the link above, the program worked well with the others
Double check that it is a c++ dll and not a dotnet dll, that one has got me before.
I have compiled Lua 5.3 as a 32 bit c++ DLL and exe. The DLL contains all the lua code except for lua.cpp and luac.cpp. The exe compiles lua.cpp and uses the DLL to run the lua interpreter. This works fine when running on its own from the command line. I wish to be able to run from the IDE using this DLL and exe.
If I replace /ZeroBraneStudio/bin/lua53.dll and lua53.exe with my own versions, I can run scripts (clicking the two green arrows). However, debugging does not work, giving the following error:
The procedure entry point luaL_addlstring could not be located in the dynamic link library lua53.dll.
I can see that this is happening because the debugger is making use of luasocket. \ZeroBraneStudio\bin\clibs53\socket\core.dll is dependent on lua53.dll, and is expecting it to contain lua compiled as c.
So, what is the correct solution to this - is it to compile luasocket as c++ as well?
(And, if so, does anybody have instructions/guidance for doing so? I have been unable to find anything on this.)
Thanks.
I'm not sure how exactly the DLL was compiled, but the error message likely indicates that the luaL_addlstring and other functions are not exported by it. If the symbols are exported correctly, you should be able to load luasocket and get the debugging working. See this thread for the related discussion.
Also, you don't need to replace lua53 library and executable, as you can configure the IDE to use your own copy of it using path.lua53 configuration setting as described in the documentation.
Okay, I was able to get it working. The solution was to compile luasocket as c++. I won't give full instructions on how to do this here, but some points to hopefully help anybody else with the same issue:
Got luasocket from here: https://github.com/diegonehab/luasocket
Renamed all *.c files to *.cpp
Renamed Lua52.props to Lua.props (I am using lua 5.3 but seems like it is compatible?)
Placed lua headers and lib in appropriate folders
Opened solution in Visual Studio 2012
Fixed up minor issues with project files, like the renaming of the files.
Added 'extern "C"' to declaration of luaopen_socket_core and luaopen_mime_core functions (necessary for lua to be able to load libraries).
Built solution
Copied new dlls into clibs53/socket and clibs53/mime folders.
I used Dependency Walker to help with this. If anybody wants further details in the future please leave a comment.
When I was going to set up my developing environment for (SDLSimple DirectMediaLayer), I downloaded the package provided by the website, from the readme.txt file I found that I need both .lib and .dll...
My question is :
I am not sure if my understanding is correct : in my thought, .lib for windows is like .a for linux, is static library, and .dll for windows is like .so for linux, is shared library, is this correct ?
If the idea above is correct, I think we can only use .lib or .dll, since the work they do is the same ? So why bother to get both two in one program ?
And I do not quite understand .dll, if my memory servers me right, the one of the advantage for shared library is they can be updated while the program is running, so how can people do this, if we update the .dll file, how can an running program get to know the changes of the .dll and reload it to memory ?
In VC, there are two kinds of libs.
First type is a "real library", generated by the "static library project", which contains everything you can link and run, without dll.
The second type is "import library", generated by the "dll project", which just contains the symbols the link.exe needs. You can link to the library, but you need the dll to run.
There are two ways to use a dll. Link to the "import library" or "use LoadLibrary API".
You can not change the dll file when the dll is loaded.
But if you use LoadLibrary to load the dll, you can use FreeLibrary to unload the dll, change the dll and then use LoadLibrary to load the new dll. Of course, you need to monitor something to invoke this procedure.
Still the easier way is that, use a loader to do the update, then load the real exe.
I have a C# class library which calls a native code DLL. I am trying to call this code from VBA.
I configured MSVC to register the generated DL and it works fine. I can access objects in DLL and work with them without any problem.
I want to register them in another computer and I am using the following command:
%windir%\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe /tlb /v MyNetAssembly.DLL
The command return successfully but when I am trying to use the dll objects in VBA, I am getting error file not found (80070002). I tried to add path to the place that dll resides, copy the dlls to windows directory, using /codebase option, without any success.
What is the problem and how can I solve it?
I have a solution in VS 2008 that creates a DLL. I then use that DLL in another application. If I go in to the DLL projects property pages and change the following configuration for a DEBUG build then the built dll no long provides the desired functionality. If I change it back and rebuild the DLL, then the DLL does provide the correct functionality:
Property Pages => Configuration Properties => C/C++ => Code Generation => Runtime Library
If set to "Multi-threaded Debug DLL (/MDd)"
then everything works as it should. I get the correct functionality from the DLL
If set to "Multi-threaded DLL (/MD)" then the DLL does not function properly...no runtime errors or anything, it just doesn't work (The DLL is supposed to plot some lines on a map but does not in this mode).
So the question is, why does using the /MDd flag result in correction functionality of the underlying code, while /MD results in incorrect functionality?
A little background...somebody else developed the DLL in C++ and I am using this DLL in a VB.net application.
All DLL's/debug code generation must match across everything that uses them. There may be another referenced library or object or dll or some code in there that is built using the wrong options; or specific options for an individual element that override the global project options.
The only way of figuring it out is to meticulously check all of the options for each file, checking the included and referenced libraries (.lib and .dll) and object files. Check the linker options too.
The reason why it doesn't work is probably because the debug version adds extra guard blocks around memory to allow detection of errors.
I had similar problems. My application which "used" a 3rd party DLL crashed when its runtime library was set to "Multi-threaded DLL (/MD)", but worked when its runtime library was set to "Multi-threaded Debug DLL (/MDd)".
It has something to do with passing std::strings and std::lists across the DLL interface.
Our guess was the low level definition of these types was somehow different in the two runtime libraries.
We solved our related problems using this rule...
The DLL and the DLL user must be build using the exact same runtime library.
The main difference between the two options is in the libraries that your code will be linked at later. for the debug version for example this will include LIBCMTD.LIB and a few others. if your library is going to be built as debug the you should always link with MDd. failing to do so will result in lots of unresolved external linker errors at best. and sometimes the code compiles normally but crashes at runtime. if this happens in vb.net then a catch can easily hide the error. I guess you should make sure you build setting is correct. for more detailed information check this.