For reasons beyond my control, an app I am working on deploying needs to use the debug version of the Microsoft Visual C++ 2005 library. I tried to register the msvcr80d.dll with regsvr32.exe and it fails. Is there a work around to get the debug libraries to register?
They shouldn't be registered, and the debug version isn't redistributable. It's best to fix the build of your project to get rid of the debug build, because you can't deploy it this way.
this is the visual studio run time library debug version. besides being non optimized this dll contains additional code to detected various run time errors. you should not use that for distribution, in addition to being slower your application might display all sorts of ungainly debug message boxes. skip the shortcut and recompile a release version.
This dll do not export DllRegisterServer and so cannot (and should not) be registered with regsvr32
If you install VC++ 2005 Express edition on each target PC that should include the non-redistributable DLLs. Then maybe you can deploy your app on those PCs.
Related
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.
I'm trying to release the mfc app which can execute without installing visual studio 2015.
First, When I'm on google, this suggested that I can execute like above by installing vc++ redistributable package.
So I've installed packages but it doesn't work.
And I got the error message. The message is like - "The program cannot start because of missing mfc140ud.dll. ...."
Second, someone said that the release app instead of debug mode can be executed without visual studio.
So I compiled the app on release mode, then I didn't get the error message but it doesn't executed. What's wrong with this?
What can I do?
You distributing a DEBUG version of your application. You can tell that by the name of the DLL it says it can't find. The "d" suffix of "mfc140ud.dll" indicates it's looking for the DEBUG version of the MFC libraries. I don't think that the redistributable contains debug version. Nor should it.
Try releasing a RELEASE build to your clients.
Your application don't run on other PC because is the debug version, compiling to release and distributing on other PC having the visual studio redistributable package will do.
If you want your application to run not depending on the mfc140u.dll you can simply static link your application with MFC. This is easily accomplished going into your project properties.
Your application exe will be bigger but you won't have to bother with these kind of errors anymore. Please note that while this method works on debug too you better not distribute debug code on other machines for a number of reasons.
I'm building a pure Win32 program (no clr or any assembly) by VC 2012 (VC 2012 (VC11) as my compiler). It uses boost 1.58, wxWidget 3.0.2 series,gsl 1.8, jsoncpp, Open CV 2.4.10, etc... The development box is running Win7 64bits. I would like it to be a single executable and is able to run on both Win 7 32/64 so I built all of the above packages as libs myself by the same VC 2012. (thanks for cmake)...
It works fine on development box but not on a clean one that only installed VC redistribution packages. I got the error message box ask me to use the sxstrace and the message in event log has side-by-side error like below and I also tried the sxstrace and got similar error.
"D:\Release\xxxx.exe" 的啟用內容產生失敗。 找不到依存組合 Microsoft.VC90.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8"。 請使用 sxstrace.exe 進行詳細的診斷。
I've been searching around. All and answers simply says I should use all release build for all libs. Yes, it's true if I didn't I couldn't have the single executable at first place. It won't be able to link. (I learned it by made lots of mistakes) I've tried both MD or MT build for my program (not mix them together. They are separated test.). Either of the mode works. The same error remains. I've also installed over lots of VC2008 9.0.21022, -.30729.17, -30729.4148, -30729.6161, VC 2010 10.0.40219, VC 2012 11.0.61030 (x86/x64)
I really don't understand. It's pure win32 release build made by VC 2012. How come it requires VC90 debug dll?
I'll really appreciated if someone can give me more precise advice about how to resolve or even determine where and what goes wrong with the code or the lib I build.
I will suggest that you use the following tool: Dependency walker.
By loading your executable on your PC (where it works) you should find out all the DLLs it uses and so discover any hidden dependencies in the (medium sized) library list on which your project depends (and in turn their dependencies).
This should help you point out DLLs that you have on your PC but not on freshly installed machines.
A pure Win32 release build should not depend on DEBUG CRT dlls, that's for sure. The only project setting to control that is basically that MT/MD ("Runtime Library") setting. You want MT.
I would guess that you have the Debug CRT dll referenced somewhere in the source code (e.g. one of the libraries requires it to be linked in for whatever reason, maybe because there is #define DEBUG or something, thus overriding project settings.
You could try searching #pragma comment(lib, ...bla-bla-bla...) in the source code.
It's resolved by myself. The project is about migrating a big legacy project. So there's a very small lib built by VC90 without source code. So be a detail person is the key to do this kind of job.
I have a C++ .exe compiled with /MDd (since I can't use CLR with /MTd). At first I was getting couldn't find x.dll that is installed when installing the VC++ runtime. After I installed the VC++ 2010 runtime, I still get the error. I've verified that the .dll it's looking for (msvcpsomethingd.dll) is located in the correct folder ([SystemDrive]\Windows\system32). Has anyone run into this problem before?
How to deploy debug CRT .dlls
How to deploy CRT .dlls in general to the application local folder
The short answer is you have to explicitly install the CRT debug runtime for VS 2010 with a custom setup project on the target machines OR ensure the CRT .dlls for the platform are in the same folder as the application.
You will have to explicitly install the CRT if you are using multiple versions of the debug CRT (i.e., x86 and x64).
The best way to solve these issues is to use the depends.exe tool. Profile the program and it will tell what you are missing.
Compile with release mode and run on different PC. It seems like one/more of your DLLs are compiled using Debug build or dependencies.
It could be your referenced library as well..
Ensure that correct Redestributable of VC++ 2010 is installed:
32-bit OR 64-bit, depending on your application, not as per target OS.
Appropriate RTM or Service Pack version.
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