Visual Studio C++ But Without Dependencies [duplicate] - c++

I created small aplication, copied exe from debug, copied textures, fonts in same folder as my exe is. In my computer, with visual studio installed i dont have any problem with running this, but on other computer i can't run this application, beacause of mvcp100d.dll(system don't see this). Is there any possibility, to run this exe in any other cumpter?

To prepare a computer to test the debug version of an application that is built with Visual C++, you have to deploy debug versions of the Visual C++ library DLLs that the application depends on. -from http://msdn.microsoft.com/en-us/library/aa985618.aspx
NOTE: Debug versions of MSVC runtime are not redistributable.

Unless you need the debug version, I would build in release mode. Not only can that be distributed, it's usually faster also. It doesn't seem to me that you are doing anything with debugging that application.

Related

Release not working on different PC

I am not so experienced with C++ and MS Visual Studio. I am currently having issue with releasing .exe and trying to run the program on different PC. In the program I'm using additional library (magick++). I've configured the Runtime Library in Visual Studio 2015 to Multi-threaded (/MT). I suppose, that with this configuration the .exe file should be running on different PCs, but when I try to run it, message with "CORE_RL_Magick++. dll is missing on this computer appears. Any idea, what might be wrong?
My second question is, if I would like to make a release with dynamic library /MD, how can I get the library to run it on different PC? Or do I have to install the library first (I mean if I have to install Imagemagick to the computer or is there some way I can get the nescessary library from the build in Visual Studio).
Thanks for every information.
Do you have CORE_RL_Magick++. dll in the path (including the directory that your exe program is running) somewhere on the computer that is failing.
The /MD and /MT commands effect what runtime is used, not what other libraries the program is dependant on.
So with /MT, it will compile a static version of the visual c libs into the exe, but if linked against the magic dll, it will still need that CORE_RL_Magick++. dll in order to run.
I think /MD is a better choice, for smaller size.
If you want to run program on other PC, you may need to install Visual Studio Redistributable (could be downloaded on Microsoft website) on the PC first.
Agree with Martin Zhai. I had this problem when attempting to run my program on another machine after upgrading to 2015. The DLL I wanted to use would not be found despite being local. Installing Visual C++ Redistributable for Visual Studio 2015 fixed this.

Deployment of Visual C++ 2008 program

I have a c++ code developed with Visual C++ 2008, which creates a .exe file in the dubug subfolder of the application. The program runs properly on the development machine, a Windows Vista PC, but does not run when installed on another machine, a Windows XP PC on which Visual c++ 2008 is not installed. (I used InstalShield 2010 to deploy the program). Even when I recompiled the program with CODEBLOCKS, it still doesn't run on the other machine, whereas it runs perfectly well on the development PC. Any ideas how to resolve this problem? Or is there any easier way to deploy C++ programs to run on any PC?
It requires CRT runtime. Standard runtime supports only release version, so deploy the release version of the exe.
The easiest way is to statically link everything. Go to your projects properties/settings and set the static link options (MFC etc). Now you can distribute just the .exe if you perfer.
Otherwise, create a new setup/deployment project. It should detect all your dependencies automatically (but you should check), and create an .msi file for your users to install your program with all dependencies together.
Also, if you're .exe is in your Debug folder, you are probably only building the debug version. You might want to build and distribute the Release version instead.

Compile (?) issue. Visual studio c++ 2008

There's an app that I use on an XP netbook for tuning a car. It was working just fine. Then I needed to make a simple modification (output to STDOUT instead of to file) so I got the source from the author.
My netbook doesn't have the space for a compiler. I have Visual Studio C++ 2008 on a Windows 7 desktop. I made the adjustments, compiled and tested on the desktop and it worked perfecty. So then I copied the executable to the netbook and it won't run
"This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem"
Original (precompiled) exe works fine. To rule out my changes, I compiled the source without the mods and it still didn't work. The executable works fine on the 7 machine as well as another Win Vista machine I tried.
So its obviously something with the XP machine and the way the executable is compiled. I really have no idea how this stuff works so I don't know what to try.
Couple of ideas:
As Keith said above this is DLL/manifest issue.
Get Visual Studio 2008 redistributable (for matching application platform) and install it on the netbook.
If this does not help: Use Dependency Walker to find out what other DLLs you are missing.
Its because a dependency / DLL compiled into your application doesn't exist on the platform you are running on.
Open windows event viewer and view the application log. There will be an entry for the error and the name of the DLL which is missing. Copy / Install that DLL on your target platform.
I would guess your vc runtime has changed with visual studio 2008 and you need to copy the latest version to your target platform. If you dont know where to get the dependency DLL, post the name here and we can see what we can do about it.
You can check your project settings and make sure to use a statically linked runtime instead of a DLL.
Project Settings, C/C++ -> Code Generation. Make sure you're using a runtime library that isn't a DLL. (So Multi-threaded Debug instead of Multi-threaded Debug DLL for example).

visual c++ 2008 release problem

I've made a simple C++ program in VC++ 2008 Pro and it runs fine in the pc I used to develop it but when I run it in a pc without VC++ installed, it just gives me a
"This application has failed to start because the application configuration is incorrect"
error. I fixed this before by statically linking my project but now when I try to do /MT or /MTD , I get a slew of link errors and it just won't go...
I've also tried installing the vs 2008 redist package too, still doesn't work.
Check my answer here.
Essentially the C/C++ runtimes are now deployed as side-by-side win32 assemblies. The embedded manifest in the compiled EXE will determine what dlls it binds to from the C:\Windows\WinSxS folder.
One question: is this a release or debug build? I would try a release build to make sure it's not a debug runtime issue (which I believe won't be present on a PC that doesn't have visual studio on it).

Visual C++/Studio: Application configuration incorrect?

My C(++) program, written and compiled using Visual C(++)/Visual Studio, runs fine on my own machine, but refuses to run on another machine. The error message I get is "This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem."
If you write a C++ program, it links dynamically to the C Runtime Library, or CRT for short. This library contains your printf, your malloc, your strtok, etcetera. The library is contained in the file called MSVCR80.DLL. This file is not by default installed on a Windows system, hence the application cannot run.
The solution? Either install the DLL on the target machine through VCREDIST.EXE (the Visual C++ Redistributable Package), or link to the CRT statically (plug the actual code for the used functions straight into your EXE).
Distributing and installing VCREDIST along with a simple application is a pain in the arse, so I went for the second option: static linking. It's really easy: go to your project's properties, unfold C/C++, click Code Generation, and set the Runtime Library to one of the non-DLL options. That's all there is to it.
The problem here is a missing DLL dependency, such as the CRT (C Runtime Library). A good tool for diagnosing this sort of problem is Dependency Walker (depends.exe), which you can find here:
http://www.dependencywalker.com/
You would run this program on the computer that generates the error message you posted, and use it to open the exe that's generating this error. Dependency Walker will quickly and graphically indicate any DLLs that are required but not available on the machine.
Chances are high that you miss the runtime libraries of Visual Studio (CRT amongst others), you can either get rid of those dependencies (link statically) or install the VC redist packages on the target computer.
Depending on the Visual C++ version you use, you have to install different packages :
Visual C++ 2005
Visual C++ 2005 SP1
Visual C++ 2008
Warning : those packages only contain release versions of the libraries, if you want to be able to distribute debug builds of your application you'll have to take care of the required DLL yourself.
It is much the simplest to link to the runtime statically.
c++ -> Code Generation -> Runtime Library and select "multi-threaded /MT"
However, this does make your executable a couple hundred KByte larger. This might be a problem if you are installing a large number of small programs, since each will be burdened by its very own copy of the runtime. The answer is to create an installer.
New project -> "setup and deployment" -> "setup project"
Load the output from your application projects ( defined using the DLL version of the runtime ) into the installer project and build it. The dependency on the runtime DLL will be noticed, included in the installer package, and neatly and unobtrusively installed in the correct place on the target machine.
The correct VC Redist package for you is part of your Visual Studio installation. For VC 8, you can find it here:
\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\vcredist_x86
POSSIBLE SOLUTION........
EDIT: (removed most of my post)
Long story short, I was having similar problems, getting the "Application Configuration Incorrect" messages, etc etc.
Depends.exe was only finding ieshims.dll and wer.dll as possible issues, but this is not the problem.
I ended up using the Multithreaded (/mt) compile option.
What HAS worked though, as a workable solution, is making an installer with InstallShield.
I've selected several merge modules in installshield builder and this seems to have fixed my problem. The modules selected were:
VC++ 9.0 CRT, VC++ 9.0 DEBUG CRT, and the CRT WinSXS MSM merge module.
I'm pretty sure its the WinSXS merge module that has fixed it.
DEBUG CRT: I noticed somewhere that (no matter how hard I tried, and obviously failed thus far), my Release version still depended on the DEBUG CRT. If this is still the case, the InstallShield merge module has now placed the DEBUG CRT folder in my WinSXS folder :) Being somewhat of a novice with VC++ I assume that this would normally be used to distribute debug versions of your programs to other people. To test if this is what fixed my problem I removed the DEBUG CRT folder from the WinSXS folder and the application still worked. (Unless something is still running in the background etc etc - I'm not that into it)
Anyway, this has got things working for me on an XP SP3 fully updated machine, and also on a VMWare XP SP3 machine with the bare bones (.net 3.5 and VC++ 2008 RTM basically) - and also on a mate's XP machine where it previously wasn't working.
So give these things a try, you might have some luck.
First thing you must use
#define _BIND_TO_CURRENT_VCLIBS_VERSION 1
or add _BIND_TO_CURRENT_VCLIBS_VERSION=1 to the preprocessor directives.
The problem is related to binding and the manifest types, you can find more http://www.nuonsoft.com/blog/2008/10/29/binding-to-the-most-recent-visual-studio-libraries/
By doing this your application will run with a larger range of runtime libraries versions.
Often times this error is the result of attempting to run the debug version of an application that uses .NET. Since the .NET redistributable package doesn't include the debug versions of the dlls that are installed with Visual Studio, your application will often get this error when running it on any other machine that doesn't have Visual Studio installed. If you haven't already, try building a release version of your application and see if that works.
Note also - that if you change to static runtime, you will have to do the same for MFC if your app uses MFC. Those settings are in properties->Configuration/General
I ran into this problem and was able to fix it very simply.
Visual studio gives you the option (on by default) to build a manifest for each build.
The manifest was put in the release folder, but it was a different release folder than the exe.
Even when using the setup utilities it was not packaged.
You should look for a file names something like myprogram.exe.indermediate.manifest
If this is in the same folder as the exe (and you have all the dlls) it should run