I have an MFC application which asks for missing dll in subject line when I run it on another computer which doesn't have VS2010 installed. I have come across solutions which says I have to install VS2010 redistributable package but really? Do we have to install that on every customer computer? That doesn't seem very good.
The interesting thing is that I have another MFC application which does the same thing as the new dll but it doesn't need the mfc100u.dll so I am confused.
Which dll your app depends on is something you can figure out with the dependency walker tool that used to come in every VS installation (now freeware)
Redistributables are packages which should be installed when deploying applications on clients pcs. Installers usually do this automatically (and often silently) to ensure that your application will have all its dependencies met.
So yes, you need to
A) figure out all the dependencies of your app
B) figure out which packages you need and then deploy them alongside your app when installing it
That's why installers are so common in the win world
There is a build setting where you choose whether to use the MFC DLL or to link MFC into your exe file. If your app consists of only the single exe file then using static linking would eliminate the need for the MFC DLL. Look for the "Use of MFC" setting in the project properties.
P.S. This setting is actually two settings: One for the debug configuration, one for the release configuration.
Related
Recently I wrote a program with VS2019, invoking Tesseract OCR dll compiled in C++ (x64) and display result on a .NET Windows form. Everything works fine on my Windows 10 dev PC. When deployed to Windows Server 2012 (x64), it crashed, complaining that the C++ dlls are not found.
What I tried:
Install vc_redist.x64.exe from Microsoft, it's still not work. (Maybe not enough?)
Run a simple .NET windows form program on that server, and it works well. (It's not a .NET problem)
Update:
I used Dependency Walker that #Fenixil suggested, and the dlls below are not found:
API-MS-WIN-CORE-KERNEL-32-PRIVATE-L1-1-1.DLL
API-MS-WIN-CORE-PRIVATEPROFILE-L1-1-1.DLL
API-MS-WIN-SERVICE-PRIVATE-L1-1-1.DLL
MF.DLL
MFPLAT.DLL
MFREADWRITE.DLL
API-MS-WIN-CORE-SHUTDOWN-L1-1-1.DLL
EXT-MS-WIN-NTUSER-UICONTEXT-EXT-L1-1-0.DLL
IESHIMS.DLL
SETTINGSYNCPOLICY.DLL
WLANAPI.DLL
Those dlls can be found in my dev PC, in C:/Windows/WinSxS, multiple files in same name under different directory. Do they belong to some Windows SP update, or are they in the Win10 platform API? What's the best way to install them instead of simply copying them to production server?
There are multiple versions of vc_redist, you need to provide one that is used in your application. Here is some discussion with vc_redist not found, might be related to your issue.
You can use Dependency Walker tool to check which dlls are missing in the system
I'm developing a dll library. My solution (cmake core, Visual Studio sln generated) consists of a few static .lib projects that are used to build this dll and the dll project itself. There are also some 3rd party dependencies (boost, nana and some more). I'm using hell dependencies manager (https://rilis.io/projects/hell) to download my dependencies. I know it's not widely used, but to put it short it is just a simple tool that after reading config file downloads dependencies using git, generates projects using cmake and compiles using the requested generator.
I need my dll to support Windows XP. I develop on Windows 10 machine and I copy the dll to Windows XP SP3 machine, which is where I run the tests. However my dll fails to load on windows xp. LoadLibrary returns nullptr. The name and architecture are matching. I'm not getting any system error, just the pointer returned is nullptr. I used to have system errors but I eliminated them by switching to functions that were present in Windows XP API. I enabled Snapping and ran profiling in DependencyWalker. I got errors about
api-ms-win-core-synch-*
api-ms-win-core-fibers-*
api-ms-win-core-localization-*
failing to load (probably also through dynamic loading during dll initialization. I found out its Windows XP compatibility issue. I figured out that I need to build my module using v140_xp toolset. Cmake provides options to specify toolset and hell is supposed to propagate this setting to build other dependencies using provided toolset. To the best of my knowledge about hell, cmake and visual studio that should be the case. However my dll still fails to load and DependencyWalker + snapping still show the same failed load attempts.
I want to know whether I missed something in my approach or if the toolset setting is not propagated to all static libraries. The second one could cause one or more of dependencies to be compiled with non xp toolset, resulting in linking with non-xp cruntime (I'm linking statically with crt - MTd/MT) and failed dependency.
I need some ideas that would help me troubleshot this issue. Anyone knows how I can check which obj or lib that my dll consists of could add dependency to non-xp API? Or maybe someone has an idea what I could have missed when building my module?
Thank you for your time!
I've created a DLL file using VC++ 2008 with following settings:
Configuration type: Dynamic Library (.dll)
Use of MFC: Use Standard Windows Libraries
Use of ATL: Not using ATL
Common Language Runtime support: Common Language Runtime support (/clr)
The created DLL is working perfectly on my machine (the machine it's created on) but it can't be used on another machine (I tested with 3 machines). For more details, I load this DLL file via JNI (Java Native Interface). On my machine it works, but on others it showing the error of "java.lang.UnsatisfiedLinkError:: The application failed to start because its side-by-side configuration is incorrect...."
My question is:
1. Did I miss any configuration when creating the DLL that can't be worked on multiple environment?
2. Can we created a DLL file that will work on different machines?
Thank you so much!
You need to make sure that the VC++ 2008 Redistributables have been installed on the other machines. To double check this is the problem run Dependency Walker on the other machine and it'll show you what it's looking for:
http://www.dependencywalker.com/
You can find the VC 2008 redist EXE on the microsoft web site:
http://www.microsoft.com/en-us/download/details.aspx?id=29
or the actual DLLs are in the redist folder in the VC 2008 install folder.
Actually you can google for "side-by-side configuration is incorrect" and you will find a lot of hints what the reason could be.
But ... giv this a try first:
In VS, project settings, C/C++, Code Generation: Set "Runtime Library" to "Multi-threaded" (or "Multi-threaded Debug".
(Btw: Do you need Common Language Runtime support?)
Besides what #snowdude says, which is correct, there is another possible problem: if these other PCs don't have VS2008 installed, and you linked to the debug MSVCR* libraries, you're out of luck. Only Release mode binaries can be deployed to user systems without hoop-jumping.
I installed XP on a virtual machine, updated it to SP3 and then tested a small program compiled with Visual C++ 2008 on my real computer - however it didn't start but outputted only an error saying that a problem had been detected and that a reinstall of the application (mine is 10KB in size and doesn't even have an installation) could fix the problem.
What is required to run programs compiled with MSVC 9?
Can I just include some dlls for it to work everywhere?
Either link statially against the runtime library (select multithreaded instead of multithreaded-dll) or follow tommieb75's advice and install the MSVC9 runtime redistributable (copying to system32 or to the application's folder works as well, but is not the way to go, afaik). For small applications with no need for an installer, I'd prefer the first option. Deploying runtime installers is annoying.
You could be missing the MCVC9 runtime library, try copying that over to the Windows System32 folder...
It may depend against which DLLs your project is linked. Inspect the assemblies manifest and check if those DLLs are installed on your VM.
What does your program contains? Dependencies on dynamic C/C++ runtime? Then you need to either include the C++ redistributable runtime DLLs in your app, or change the program to use the static C++ runtime. Similarly, do you use ATL? MFC? Custom 3rd party libraries? They all add dependencies to your executable and Win32 will refuse to load your application.
One easy step is to check with Dependency Walker what dependencies your application has.
It could be a dll you application links against. The depends tool is a must have in every programmers toolbox for debugging dll dependency issues.
If you have the commercial rather than express msvc edition, what you really should do is copy the msvcmon redist components to your VM, run the remote debug monitor there, and attach to it from your desktop dev environment. This page explains the basic principal. Because it sounds like your app is causing an exception on XP.
If you can't remote debug and if dependency checker does not indicate a dll issue, then you could look in the systems application event log to see if there is any more information there. Or try install Dr Watson as a post mortem debugger. Open a command prompt and enter
drwtsn32 -i
to install Dr Watson as the post mortem debugger, and
drwtsn32
to get a config screen allowing you to browse for the location of crash dumps. You can load crash dump files directly with Dev Studio 2005 and later. (I don't think Dr Watson ships with Vista and Windows 7 anymore).
I've been trying desperately to get my application (15 C# dlls and 1 C++/CLI dll with C++ Runtime DLL dependencies) to deploy with ClickOnce. I got it to work by just copying the Release folder, but ClickOnce refuses to copy the files (msvcm80.dll, msvcp80.dll and msvcr80.dll) and deploy them in this folder.
I did this nutty workaround (supply msvcm80.dll, msvcp80.dll and msvcr80.dll as Content/Copy If Newer and then at startup, create the Microsoft.VC80.CRT folder, copy those DLLs, and create Microsoft.VC80.CRT.manifest) that seems to work, but this all just feels wrong to me.
Am I missing something?
I'm stupid: I just found this:
On Publish tab of Properties page of my startup project: click Prerequisites... button > check Visual C++ Runtime Libraries, radio button setting: Download prerequisites from the component vendor's web site.
It seems to work the way one might expect!
There should be a msi from microsoft that deploys those for you. I used....
instructions
and download vcredist_x86.exedownload