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
Related
I'm new to Qt, but have been working with Visual studio for C/C++ development for a few years. Now I'm trying to build a GUI for my project. I installed Qt 5.11.0 and the Qt VS Tools on both my work computer and home PC. At work I can build and run my project with the VS debugger, however on my home system I can build but can't run either with VS debugger or simply launching the app. I tried in release and it runs fine.
The error I'm getting is :
The code execution cannot proceed because VCRUNTIME140D_APP.dll was not found.
I get 4 of these, the first two want VCRUNTIME, the second two want MSVCP140D_APP.dll.
Solutions I've tried so far :
Uninstalled Win SDK and reinstalled
Uninstalled VS2017 and SDK and reinstalled
Searched System32, SysWOW64 and VS install directories - found msvcp140d.dll and vcruntime140d.dll, but no _app.dlls
Does anyone know what these are included with and where to get them? I can't figure out why I have them on my work computer but not at home. I have the same VS updates, same Qt version, and SDK on both systems.
Using :
Visual Studio 2017 v15.7.1
Qt 5.11.0 - msvc2017_64
I suppose I can just copy the .dll's from my work pc and drop them in the appropriate locations on the other, but I'd like to know what they should have been installed with so I can have the same setup on both systems.
Edit:
I also tried changing the platform toolset to VS2015 with Qt versions msvc2015_64 and winrt_x64_msvc2015
I found this post concerning the same missing _app.dll files. There wasn't any answer there, which is why I tried reinstalling the SDK in the hope the missing files were included there.
Edit 2:
I just scanned my entire system at work and it turns out that I don't have the missing .dll there either. That tells me that there is a difference in the project properties or configuration between the two. I use git for source control, and I am currently the only contributor to this project. When I try to build and run just the example from the getting started guide I have the same problem at home with missing _app.dll files, however it works fine at work. I'm totally confused now, and any hints are greatly appreciated.
Solution:
After trying for a couple of hours making new solutions etc. I decided to delete the entire build folder and put fresh copies of all the dependencies into it. My project now runs fine in debugging mode.
I'm fairly certain that when I originally copied the Qt .dll files into it I must have grabbed them from one of the winrt folders rather than the msvc2017_64 folder. To test I replaced the working .dll files with those from the winrt_x64_msvc2017 folder and sure enough the same errors again. So, this was a dumb mistake on my part, but hopefully it'll save someone else a lot of hair-pulling in the future.
I created an application using Qt 5 (compiled with Visual Studio '12). It works on my machine.
However, it doesn't work when I attempt to run it on another machine. The output I collected through cmd yielded an empty file.
The directory structure is as follows:
myapp.exe
icudt52.dll
icuin52.dll
icuuc52.dll
libEGL.dll
libGLESv2.dll
msvcp120.dll
msvcr120.dll
Qt5Core.dll
Qt5Gui.dll
platforms/qminimal.dll
platforms/qwindows.dll
The most relevant post I found was Application deployed with QT5 libraries does not start on Windows 7 - yet the solution (including qwindows.dll & qminimal.dll) didn't work.
Any ideas?
Windows will report a number of launch errors just when you double click on your exe outside Qt Creator. It looks like you have included most or all of these already.
Your development machine typically will not have problems launching and running its qt plugins because of the LibraryPaths that are searched by your exe. http://qt-project.org/doc/qt-5/qcoreapplication.html#libraryPaths
Dependency Walker will do the job and show you what you need to know, but the output is pretty complex and can be hard to decipher.
The easiest way I have found to figure out what Qt plugin dlls I am using at runtime on Windows is to do the following:
Exit Qt Creator.
Open the install folder for the compiler you are using with Qt in Explorer. For example:
C:/Qt/5.3/msvc2010_opengl/
Create a copy of the plugins folder in place (Copy of plugins folder in the same path as plugins, so its parent is msvc2010_opengl in this case).
In another explorer window, open your exe (Qt program) on your development machine. Run a minimal test of your program to make sure the major features are working. (Many runtime plugins don't get loaded until QObjects that use them are instantiated).
Delete the plugins folder in the Qt path.
Windows will lock up all the dlls that are in use by your exe and prevent you from deleting a number of dlls. Click skip for all the un-deletable folders and files.
Now go into each of the folders that you couldn't delete before and try to delete all the individual dll's in each folder. Click skip for all the un-deletable dlls.
Now when you are all done, you are left with a skeleton of a plugins folder, only showing dlls that your application is using.
It will probably include the folders: accessibility, platforms and imageformats and more depending on what you included in your .pro file.
Close your exe.
Copy the contents of your stripped down plugins folder to sit right next to your exe.
Restore your backup of the plugins folder (delete the stripped down plugins folder from your Qt path and restore the Copy of plugins).
Now you should be good to go. Test on a non-development machine.
A Note on VS C++ Runtimes
Also on some machines when deploying Qt with MSVC, the msvcrXXX.dll doesn't match what the rest of the system is using. Instead of deploying msvcrXXX.dll, instead in our installers at our office, we include the Microsoft C++ Redistributable Installer and run it in the install script. And on a few machines they had corrupted Redistributables, and we had to do a force install of redistributables to fix the `Referral from server' error we would sometimes get.
You can find the latest installer for MSVC Redistributables here Latest Supported Visual C++ Downloads.
Hope that helps.
You have to deploy your application before copying dll files manually.
To deploy your Qt application on Windows you can use windeployqt which can be found in:
< QTDIR >/bin/windeployqt
Example batch script may work on deploying your Qt Application (run with PowerShell or cmd):
C:\Qt\Qt5.x.x\5.x.x\MSVCx_x\bin\windeployqt <APP_PATH>/myapp.exe
After deploying your app, try to run your myapp.exe and note which dll files are missing.
Copy / paste required dll files from QTDIR/bin to your < APP_PATH >
for more information about deploying:
Windows Deploying Tool - windeployqt
Deploying on Windows
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.
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).