How can I use my DLL in other computer? - c++

I developed a dll project with opencv and tesseract then I use it in C# WCF service project via CLR. When I try to import my dll in other computer, It give dependency error.
In my opinion, this error depends on used opencv and tesseract libs in dll. So how can I solve this issue ? I want to use this dll in other machines.

Use Dependency Walker utility to understand what dlls you should deliver with your application to the other computer.
On the other computer with this utility you can understand what dlls are missed.
You should inspect dependencies not only for your application, but also for OpenCV and Tesseract. These dlls dependent of MS VS Redistributable dlls which could also be missed on the target computer.

Nowadays it is best to create a setup for your installation containing all dependent DLL's
There are several free programs that make it simple to create a setup if you do not want to use the built in one in Visual Studio e.g. InnoSetup

Related

DLL hell and deployment: best practice for native windows applications

I'm trying to get a handle on which DLLs my native mode C++ win32 application uses. This isn't always obvious - I can link a library but it's somewhat more difficult to find out which system DLLs are needed, particularly if they're system DLLs.
As a case in point, I recently sent a test build to a remote member of my team who's running an older version of windows.
his machine complained about
'api-ms-win-core-misc-l1-1-0.dll' being missing (I assume this had something to do with my using 'GetSystemTime' and related functions but that's part of my problem: how do I tell?) but seeing as this is a windows system file, how can I package up an installer that will ensure these files are installed?
Also, I've used dependency walker and 'listdlls.exe' to find all the DLLs used by my program but dependency walker can't load that DLL and 'listdlls' seems to silently ignore it, so I can't find their location in order to redistribute them (which feels like the wrong approach anyway).
My question therefore is what's the current best practice to:
comprehensively determine all the system DLLs that are used by my
application
write an installer that ensures these libraries are
installed on a users machine
Find out which redistributable installers are needed from a given list of DLLS
I would have thought that installing a visual studio redistributable
package (e.g.
https://support.microsoft.com/en-gb/help/2977003/the-latest-supported-visual-c-downloads)
would be enough. To my knowledge, the team member has installed this
but still gets DLL issues.

Statically link with Microsoft CRT, and OpenMP

I’m developing some Windows software that's sometimes used in embedded-like scenarios. That’s not uncommon for my users to have a dedicated Win7 or Win8 PC they never update, not even connect to the Internet. Users plug those PC to a specific industrial hardware, and use that system for one job only.
My software includes components I've written in Visual C++. I include CRT in my MSI packages using appropriate installer merge modules.
Unfortunately, for a PC that never updated, that doesn’t work: today I got a bug report, the app crashes on startup saying “can’t start because api-ms-win-crt-stdio-l1-1-0.dll is missing from your computer”
This answer suggests static link to CRT.
Did that. But some parts of my C++ code rely on OpenMP for parallelism.
Dependency walker shows me the DLL I’m building depends on vcomp140.dll even when compiled with Multi-threaded (/MT) runtime library settings.
Also it shows vcomp140.dll only depends on kernel32.dll and user32.dll.
Can I just place that single DLL, vcomp140.dll, in the installation folder? Will it work on offline Windows 7 PC?
Based on the VS2015 Redistribution List I would say that copying that file would be indeed what you need to do and would work fine (if you used VS2015 to build your app). Take care to copy the proper dll based on arm/x86/x64.
Just to make it clear, it is not possible to statically link openmp with Visual Studio. Only two things you can do:
Remove openmp (and compile with /MT /MTd)
deploy vcomp140.dll (or VC redistributable) with your application

creating C++ program that runs on most of PCs

I have a project that requires writing a code for small executable file. I used visual C++ express 2010 IDE to create this file. After I finished writing the code, I tried to copy it to a couple of different PCs. It gives me an error message every time I clicking on this file to execute it. The message states that I have to install (.NET framework). I watched a couple videos on YouTube explaining how overcome this problem by changing the runtime library from multi-threaded Debug DLL (/MDd) to multi-threaded Debug (/Mtd). However; the IDE can’t debug the C++ code because when I create my project by using CLR template!
Is there any way to solve this problem? Can I create a similar program that not requires any further downloading once I using on different PC?
Is learning a different language like JAVA or C# will help creating small programs (like my program) that run on most Window platform machine?
Just use Qt - it runs on Windows, Linux, MacOS, support for Android and iOS is scheduled for this year, plus it supports embedded platforms and some of the more obscure mobile platforms. Also, support for Windows RT was just kickstarted. A complete library with tons of functionality, good documentation and lots of educational resources. It provides tons of tools, from implicitly shared containers through threading, signals and slots, 2D and 3D graphics, widgets, multimedia, sensors... and whatnot...
You can even develop commercial applications under the LGPL license.
Also comes with a pretty good IDE - Qt Creator.
You can develop standard C++ applications or use QML, which is a JavaScript like language for markup and scripting, which is used to build applications from C++ implemented components. You can also extend QML. It is much faster to develop with QML and you still get the advantages of platform native binary under the hood.
Note that you will still need to either ship a few DLLs with your application. Unless of course you use a static build, which requires you to either have your application open source, or purchase a commercial license... which doesn't come cheap...
But still, a few MB of DLLs are far better than the entire .NET framework. A static build will produce executables about 8-9 MB with no external dependencies.
Stick with the C++ standard, avoid Microsoft extensions (managed code), and call only POSIX functions of your OS, then you should be able to write portable programs.
You seem to have created a Managed C++ Project. Instead create an empty Win32 C++ project and then add in your .cpp/.h files. This will limit you to the default libraries available on all PCs with the C++ runtime. If you want to remove that dependency too then statically compile in the runtime using the /MT option. Details # http://msdn.microsoft.com/en-us/library/2kzt1wy3(v=vs.71).aspx
As you move ahead you would need to be conscious of what libraries you take dependencies on and what versions of the OS are those libraries available on or if you need to package them with your bits.
Both Java and C# will help making portable programs. Usually, people will have to install runtime environments for executables written in these two languages, however. These days, C++ is more portable than ever. You can easily run C++ executables in your browser:
https://github.com/kripken/emscripten
http://code.google.com/p/nativeclient/
This makes many of the reasons why Java and C# came about irrelevant.
Open standards like OpenGL also make portable GUI programming easier than ever. Try Qt, if you want to write a simple GUI in C++.
Note: It is possible to run C++ program in any computer without installing anything if you haven't use .NET framework. In your case, there can be two reasons to trigger error in target computer.
New computer doesn't have required run-time assembles.
New computer doesn't have required .NET framework installed.
..........................................
So what to do:
Before start your program you have to design weather are you going to use .NET framework support or not. If you use .NET framework when you develop your program, then you much install same or higher .NET framework in target computer.
If you no need to use .NET component then your target computer should only containing run-time assemblies.
How to get rid of .net framework
right click on the project in solution -> properties -> General -> Common language run time support -> select "No common language run time support".
..........................................
Then what you need is only relevant run-time assemblies be in target computer.
How can run-time assemblies be in new computer:
There are two ways:
Install suitable C++ disputable environment in target computer(if you use VS2008 SP1, C++ RD package should be this. Please consider the solution build architecture also (32 bit/64 bit) before download ).
Deploy run-time assemblies with your solution package. (I like this because user no need to install any third party components)
..........................................
How Deploy assemblies with my project:
for this your all DLL, LIB, EXE should use same run time version.(if not, you face troubling to redirect assemblies by 'manifest' files ).
How to check the run-time version.
open DLL,EXE by visual studio (open->file) -> expand RT_MANIFEST-> double click the file under it ->then assembly dependency details will open. -> copy the data in right column and paste to note pad.
You will see this kind of line there. and ther is the version run-time assemblies your specific DLL or EXE use.
assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.21022.8" processorArchitecture="x86".....
After identifying the version of run-time assemblies follow this tutorial and try to run in fresh installed computer.
At last: If you think this bla.. bla.. is so complex and your program is very simple, then you can consider about "run time assemblies statically linking" (try Google). But personally I don't like this method.
good luck!

C++ Dll in Dependency walker shows IESHIMS.dll and MSVCR110.dll

I've a dll which I've built in Windows7 (64bit OS) in 'Win32' platform. Unfortunately, when I import this dll in C# code, I encounter:
"
an attempt was made to load a program with an incorrect format
HRESULT: 0x8007000B
" is observed
When I used DependencyWalker for this DLL, it shows IESHIMS.dll and MSVCR110.dll dependency which could not be found.
From where these dlls come from and why my created dll has dependency over these two?
Pl help how can I getg over this?
Note: I've used x86 platform in my C# code.
IEShims.dll is available on Windows Vista or Windows 7 to handle protected-mode Internet Explorer 9 or newer. Further explanation here.
You should be able to obtain a copy from another Windows 7 machine with Internet Explorer 9 or newer. As a quick fix, get the Windows 7 version from http://www.dll-files.com/dllindex/dll-files.shtml?ieshims
You probably don't have the C++ runtime installed. Download it and install it. You have to play with the versions of runtime a bit. There are quite a few versions available. This will take care of your MSVCR110.dll issue. I am not sure why the dll show dependency for an IE dll though.
Make sure you chose x86 for the target architecture in the properties of your C# project.

When do I need MSVCRT redistributables ?

I've built a MFC application in Visual studio 2010 and I'm scratching my head about including the redistributals in the installer.
The application is statically linked, so I should not need the redistributables, its selfcontained, right ?
Here is an an easy way to test if you need the redistributable:
Install a clean Windows 7 on a VirtualBox (or even better Windows XP SP 2, because it doesn't have the basic stuff you would expect)
Run your software on this VirtualBox
If it doesn't work, you probably need to include the redistributable.
Yes it should be OK but I would install on your intended target platforms and see if it works, if not then you would need to add more dlls or add as a pre-requisite to install the VC resdistributable before installing your app.
Although you may have included the MFC dlls, the Visual C runtime may be different on your target OS so you may still need to include the VC redistributable with you app.
MSDN link about doing the above: http://msdn.microsoft.com/en-us/library/ms235299.aspx and walkthrough: http://msdn.microsoft.com/en-us/library/dd293575.aspx
Any time you statically link a DLL or redistributable, you do not need to redistribute it. That's the core difference between static and dynamic linking.
It'll actually embed the parts you use (or the whole thing, depends) into your application. By redistributing your app, you are, in effect, redistributing its dependencies as well.
Note that you can't always use static linking and it doesn't always make sense to use it even when you can.