I have a win32 console project that have successfully compiled in 'Release' mode. I wonder if I can just deploy that stand-alone exe or should I have a setup program. If I do need to set up program, could someone help point to some helpful tutorial for setting up such a project. The project is compiled with 'Use MFC in a Static Library' setting.
Any help would be great.
First, you'd better check which platform your project compile for. You can prepare both x86 and x64. Then, for each platform, find correspond runtime dlls, such as msvcr120d.dll, mfc110d.dll and distribute them with your standalone exe. To find all necessary dlls, you can execute your standalone exe on another clean computer, and lost file name will be on message. An easy way is to use Visual C++ Redistributable, but it is a little bit large.
Related
Recently I switched from mingw to msvc compiler for my Qt app.
I am using Qt5.8. The msvc debugger is from the windows 10 kit (though I develop on Win7 and Win8.1) and the compiler from the vc++2015 build tools.
I can run the app locally, but I can't run it on a different, clean computer.
I know that I have to copy the compiler specific dll's to the application's executable directory. All the other dlls are found by windeployqt. Still I don't get it to work. I can't ship vc_redist packages the user has to install, due to the requirement to be able to load the app from a pendrive. On the dev machine there are several dlls of the same name, how can I figure out which ones are actually used by the compiled app?
Questionable dlls is especially api-ms-win-crt-runtime-l1-1-0.dll.
On the deployment I got those errors:
I also tried Dependency Walker and showed the full paths. I assume the first hierarchy level is the important one, that's why I've hidden deeper hierarchies. I am wondering why the full path shows the dir System32 because isn't this the 64-bit files folder?? I did not target any specific one but my app must be running on x86. Is this a misunderstanding?
EDIT
According to another question and this Microsoft blog update it worked for me when I additionally included all dlls from this folder C:\Program Files (x86)\Windows Kits\10\Redist\ucrt\DLLs\x86. There is also a file named ucrtbase.dll. I have no idea why DependencyWalker showed different ones.
You can use tools such as Dependency Walker to see which DLL is used by any other DLL or exe file.
Edit: You can also take a look at Determining Which DLLs to Redistribute on MSDN
Also you could use static linkage to link against the MSVC runtime (i.e use /MT switch instead of /MD (see https://msdn.microsoft.com/en-US/library/2kzt1wy3.aspx). However this would also mean rebuilding Qt, but it would also give you the opportunity to build a static version of Qt, meaning that you would not need to ship any DLL alongside your exe. You can find more info on Qt wiki: Build Standalone Qt Application for Windows
How can I deploy my Win32 application as an EXE application so that others (who don't have VC++ installed) can use it?
I am using VC++ 2010 on Windows 7.
If you switch to "Release" mode when you compile your finished program (rather than "Debug", which you use for debugging it during development), you should get an executable that will run on a computer without Visual Studio installed.
However, that executable will still require the appropriate version of the C runtime library to be installed. For example, if you developed it in Visual C++ 2010, you will need version 10 of the CRT installed. This is a freely redistributable library, downloadable here.
So, you have several options for deployment:
Manual Deployment
Give people the bare executable file, and include the installer for the redistributable in another folder on the installation media. If they copy the executable to disk and cannot run it because they get an error message, they should install the CRT libraries from the included redistributable installer. Then the executable will run just fine.
This works great if you have relatively a computer-savvy audience, or you're deploying to a fixed range of machines (like across a school or corporation). But it doesn't work so well for general deployment to customers.
In fact, you don't even need the installer. You can just place the CRT DLLs in the same folder as your executable and it will run just fine. This is how I test apps I'm developing on clean VMs. It works like a charm. There's no need to run the CRT installer at all. You'll find these required libraries as part of your Visual Studio installation:
<Program Files folder>\Microsoft Visual Studio 10.0\VC\redist\x86
Automated Deployment
Create a setup program that automatically installs your application along with any dependencies it requires, including the CRT redistributable. This is what you see most commercial applications doing. I recommend it for anything but the most trivial of apps.
Full versions of Visual Studio 2010 (i.e., not Express versions) can create a Setup Project that you can customize as needed to work as an installer for your application. But this is no longer the recommended way to create an installer, and this functionality has been removed from the latest version of Visual Studio, 2012.
So I recommend using something else, even if you have an older version of VS where the Setup Project is available. No point in wasting time creating something you'll just have to update later. My personal favorite choices for creating setup programs are WiX and Inno Setup. Both are free, and extensive documentation is available online.
Creating simple setups that don't have to do very much is really quite straightforward—this is likely the case for you, as all you need to do is install the CRT redistributable if it is not already there. I'd be willing to bet money you can find a walkthrough or example online for how to do this in either WiX or Inno Setup.
If you need to do more complicated stuff, both of these setup packages support it. They are extensively customizable and very powerful, it just takes more work to get it all going.
Static Linking
If you absolutely need to be able to distribute a bare executable that is guaranteed to simply work when double-clicked, you will need to switch your project to statically link in the required runtime libraries. This means that all of the CRT code is actually embedded by the linker directly into your executable, and means that you don't have to redistribute the CRT libraries separately.
The disadvantage of this approach is that the only way to benefit from improvements, bug fixes, and security patches released for the CRT is to recompile and redistribute your application. If you dynamically link (the default), your app will automatically benefit from enhancements to the installed version of the CRT libraries. Microsoft strongly recommends against static linking.
To switch between these modes in Visual Studio, follow these steps:
Right-click on your project in the Solution Explorer and select "Properties".
Ensure that the "Release" configuration is selected in the drop-down box at the top of the dialog.
Expand the "C/C++" item in the TreeView, and select "Code Generation".
Change the setting of the "Runtime Library" option to "Multi-threaded (/MT)".
A further description on what these cryptic compiler switches mean and which ones you should use when is given in my answer here.
Final Note: The "Debug" versions of the CRT libraries are not redistributable, but that doesn't matter because you should always distribute the "Release" build of your app anyway, never the "Debug" build.
In general, the odds are pretty good your EXE file will run on any version of Windows you built it on or higher.
All bets off, for example, if you built using Visual Studio 2012 Professional on Windows 7, and you try to run it on Windows 95. But otherwise, you're probably safe :)
The best way to test if you have any dependencies is to install and run on a "clean machine".
The best way to get (and reuse) a "clean machine" is with a VM.
I recommend VMWare. But Virtual Box and Windows Virtual PC are also viable choices.
As far as an installer, I'd strongly encourage you to look at InnoSetup
I hope that helps!
Make sure you build in release mode. As Floris Velleman said, you're using unneeded libraries for standalone executable.
For more information, you can check Compiler Options (MSDN).
I've build a project with opencv, when I share my .exe on other pc they can't find some dlls, this happens in release and debug mode, I searched on the web and I know I must configure the properties of the project, I tried configure MFC but with all the configuration the problem persist.
thank you!
Are they SystemFramework libraries? Or are they libraries that your app specifically uses, ones that you have imported into the project?
If they are your custom/imported libraries, make sure you copy them to output, and send them with the exe. The point of an installer is to bring the client your executable will of the the files it need to reference, compiled into a single file.
It seems the runtime librarie of opencv are missing. I'm not familiar with opencv, but VS provides a way to find all dependencies: http://msdn.microsoft.com/en-us/library/vstudio/dd293568.aspx. You can build an installation package for your application.
Another way to find all dependencies is using depends.exe, details are in:http://msdn.microsoft.com/en-us/library/ms235265.aspx
I wrote a C++/CLR Windows Form program and it works fine on the compiler computer but not on any others. The target computers have .Net4 and the C++ redistribution pack. I really don't understand how the settings need to be set and the info on the web concerning this stuff is very confusing for a beginner. How do I need to have my compiler set so that I can get this program to run? If I need to link .dll's how do I go about doing that. Here are the key settings as I know:
The Runtime Library is set to /MDd; MFC:Standard Windows Libaries; ATL:Static Link to ATL; CLR:/clr:pure.
Edit: If I install VS on taget computers I can open the .exe without a problem, not even opening VS or loading any source files. It seems it's still dependent on VS somehow, any idea's on this and how to over come it?
/MDd specifies a dynamic debug CRT, this won't be installed by the standard CRT redistributable MSI
Try putting a release build on the target machine instead.
I have developed a Win32 Console app DLL and a small tester application for it. As far as I know neither uses MFC, .COM, .NET or dot-anything else. Development platform is VS2009 on WinXP/SP3
When I give the DLL and EXE to someone else, they are unusable. Attempting to use them generates errors similar to "Application cannot be used, the application configuration is wrong." and "cannot find xxx.dll" (not exact wording on these error messages).
I have learned from reading that there are dependencies that must ship with the EXE and DLL. These dependencvies seem to be specific to VS 2009 abd should include the MSVCRT09, etc.
When I followed MS's instruction to make a setup.exe/MSI installer for a Setup and Deployment Project (http://msdn.microsoft.com/en-us/library/ms235317%28v=VS.90%29.aspx) I add the dll to the project, move it to the "MyLibrary" folder and no dependencies are found or listed in the Solution Explorer. Yet, I know there are dependencies, DEPENDS.EXE says so.
Can anyone walk me through this or name a better site with instructions. Once again, MS's help isn't all that helpful.
thanks,
Wes
Visual Studio 2008 is version 9.0. A program built with Visual C++ 2008 normally does have dependencies on the C run time library MSVCRT09, as you discovered. If the C run time library is not installed on the destination PC (either already installed or as part of your setup project) then your application fails, as you discovered. It is no surprise that DEPENDS.EXE displays the dependency. The only question seems to be why Visual Studio 2008 doesn't display the dependency in its Solution Explorer window.
Before building your Visual Studio setup project (MSI and setup file), Visual Studio might not have had any reason yet to search for dependencies. But after the setup project is built, in my experience the Solution Explorer does show the dependencies it found, next to other dependencies that you set explicitly. If those don't show up after building, something is weird.