I am writing an installer using wix. I have also written custom actions. But while installing the MSI the installation fails because the target system does not have MSVCR100D.dll
I am linking using /MTd option which is what the docs I read suggested for static linking.
Can anyone please let me know how to link msvcr100d.dll statically so that even if msvcr100d.dll is not present on the target system, my MSI installation succeeds?
The "D" in MSVCR100D.dll indicates that your native custom action DLL is a debug DLL. The "D" dependency won't be on the target machine unless they have various SDKs installed. Rebuild your DLL in release and the dependency will change to MSVCR100.dll
Also, since you are using WiX / Votive, there is a Visual Studio WiX C++ CA project type that creates the project for you. My experience has been that all of the default compiler and linker settings are good to go out of the box when you use that project type.
I have noticed the same problem. In my case, I am trying to debug my custom actions running in the context of the installer, so I do want to install debug versions.
The Visual Studio debug CRT DLL's are not redistributable, by Microsoft policy. Apparently, it seems furthermore that a 64-bit DLL compiled with Visual Studio 2010 using /MTd (static linking, debug configuration) produces output with a dependency on MSVCR100D.dll. In the 64-bit release configuration, as expected, compiling with /MT results in no dependency on MSVCR100.dll.
One solution is to install Visual Studio on the target test machine. Microsoft offers further suggestions here.
Related
I have built a 64-bit application with C++Builder XE3 that is running on a Windows Server 2003 (32-bit). I can compile it, but of course cannot run it in that computer.
I copied the .exe over to a Windows 7 (64-bit) computer and now it's complaining that rtl170.bpl cannot be found. I have explicitly set the project options to not use any Runtime Packages.
Is this a bug in XE3 or does it fail because I am building the application on a 32-bit computer?
You also need to disable the "Use dynamic RTL" (linker).
You can use Dependency Walker to check the dependencies for a binary (exe, dll, etc.) that you have built.
This will show exactly where the dependency is coming from. One possibility is that your code depends on some other library or DLL, which in turn depends on rtl170.
Another thing to check is that you are actually looking at the right Project Options for what you are building. For example, say you are doing Win64-Release, then in Project Options, make sure the "Target" combobox says "Release configuration - 64-bit Windows platform" when you are on the "Runtime Packages" field. (At that stage, "Link with runtime packages" should be unchecked).
Do a full rebuild of the project after confirming this setting, and of any dependent libraries you are linking. (Example - if you also built OpenSSL and are linking to that, make sure that you had "Link with runtime packages" off for the build of OpenSSL).
In my case, I had to enable/disable the following settings under project options
Packages
Runtime Packages
❌ Link with runtime packages
C++ Linker
❌ Link with dynamic RTL
❌ Link with Delphi runtime library
✔️ Disable incremental link
I am using JNI to interface to a CAN driver I wrote using MSVC++ 2012. Everything compiles and runs fine - but only on my computer. Whenever I try to run on any other computer, I get the JNI "UnsatisfiedLinkError" - can't find dependent libraries. I've implemented JNI before, and typically this issue is resolved by simply installing the Microsoft Visual C++ Redistributable Package before running my program. The Redistributable does not solve my issue, however, installing the entire MSVC++ Express 2012 IDE on the computer in question seems to make everything work just fine. Thus, I assume this means that there is some dependency that gets installed and added to PATH when the IDE is installed but not when the Redistributable is installed. Just for verification, I uninstalled the IDE and my JNI driver failed to load once again. The primary difference between this and my other implementations of JNI is that I use Windows.h since it is required for the CAN API I use in my driver. Any ideas on any libraries installed with the IDE but not the Redistributable and whose prototypes are included with Windows.h? (Note: I am aware that Windows.h includes a number of headers itself but I imagine the other criteria make the issue a bit more specific.)
First guess: You are installing a debug build intead of a release build. Debug builds depend on debug versions of the CRT, which cannnot be redistributed.
Check that you are using the right "Microsoft Visual C++ Redistributable Package". There are 2012, 2012 Update 1 and 2012 Update 2 (as well as many for 2010, 2008, ...).
Assuming your dependencies are load-time DLLs, you can use Depends to find out what's missing. (Note: you'll typically see some delay-load DLLs that are "missing". Ignore thoses; See the FAQ.)
Of course, once you find out the name and path of the missing DLL, you'll have to find out what redist package installs it.
I have designed an application that requires no install and can be used by non-administrators. I would rather not lose this functionality but when I use the .exe on other computers than the one I programmed it on I get an error that a missing MSVCP100.dll is preventing the file from executing.
What am I doing wrong here? How do I include the file in my release build?
Thanks!
Configure your project to statically link to the C/C++ runtime instead of linking to the runtime DLL:
Configuration Properties | C/C++ | Code Generation | Runtime Library
Select Multi-threaded (/MT) (or Multi-threaded Debug (/MTd) for your debug build).
As an alternative, you should be able to get xcopy deployment of the C/C++ runtime DLL using the technique documented on http://msdn.microsoft.com/en-us/library/ms235291.aspx under the heading "Deploying Visual C++ library DLLs as private assemblies". I haven't tried that technique, as it's generally simpler to just statically link if you need xcopy installation of a native C++ program.
http://msdn.microsoft.com/en-us/library/ms235299.aspx
Distributing apps that have been compiled with Visual C++ requires distributing the C++ runtime .dlls that your app uses. In your case, I assume you want to just distribute a folder, so follow the directions (appropriately modified for your app) here:
http://msdn.microsoft.com/en-us/library/dd293565.aspx
Or just copy msvcp100.dll into your application's directory alongside the .exe and you'll be good to go.
32-bit msvcp100.dll is in C:\Windows\SysWOW64\
64-bit msvcp100.dll is in C:\Windows\System32\
What am I doing wrong here
What you had was dll hell. You had unintentionally used a dynamic linkage with the previous compiler where it just happened on most target systems there was an appropriate C runtime. Windows often included VC 6 CRT, and with more recent SP even VC7 & 8 CRT.
When you changed to the latest VC compiler most systems will not have the new VC runtime pre installed for you.
As Michael Burr says, you can have your 'no install' back if you link statically.
Or you could include the CRT and manifest in the same folder, still doesn't require install.
Or include the vcredist.exe from VS2010 and have a 1 off install
You need to install Microsoft Visual C++ 2010 Redistributable Package.
How to include the windows runtime dll files in setup project.
without vc++ 6.0 software in the machine the project must execute.
or give me the hint how to make a the project setup(EXE) in vc++ 6.0 ,i am using create installor,
You can modify the project settings to link statically to the C runtime (I assume this is what you mean when you said windows runtime ?). The static link flags are:
MultiThreaded static linkage (/MT)
MultiThreaded debug static linkage (/MTd)
Sorry, been awhile since I used VC6.0, so I had to check the GUI. You'll find this in project settings, C++ tab, Code Generation combo box, "Use run-time library").
To add to what Cannonade has already said, if you are doing it through Visual Studio, then this can be done through Project Settings->General Page->Use MFC as a static library. This way your created exe will be ready to run on any windows box.
This is the error Dependency Walker gives me on an executable that I am building with VC++ 2005 Express Edition. When trying to run the .exe, I get:
This application has failed to start because the application configuration
is incorrect. Reinstalling the application may fix this problem.
(I am new to the manifest/SxS/etc. way of doing things post VC++ 2003.)
EDIT:
I am running on the same machine I am building the .exe with. In Event Viewer, I have the unhelpful:
Faulting application blah.exe, version 0.0.0.0, faulting module blah.exe,
version 0.0.0.0, fault address 0x004239b0.
Open the properties sheet for your project, go to the Configuration Properties -> C/C++ -> Code Generation page, and change the Runtime Library selection to /MT or /MTd so that your project does not use the DLL runtime libraries.
The C/C++ DLL runtimes used by VS2003 and up are not automatically distributed with the latest version of the OS and are a real pain to install and get working without this kind of problem. statically link the c-runtime and just avoid the total mess that is manifests and version specific runtime dlls.
I've had this problem. The solution has two steps:
1. Compile your program in "Release" mode instead of "Debug" mode (there's usually a combo-box in the toolbar)
2. Download from Microsoft their Redistributable Package of runtime components. Make sure to download the x86 edition for 32-bit computers and the x64 edition for 64-bit computers/OSes. Install this package on the target computer, and your application should run fine
P.S. This is a SxS thing
P.P.S. Alternatively, use a different compiler (like GCC, for example with Dev-Cpp) to compile your program's source, and your headaches will disappear.
Sorry to bump an old question, but I was able to get around this exact issue and thought I'd post a solution in case someone else needs it...
Even after installing Microsoft's redistributable DLLs I was getting this error, the fix was to copy the
C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT
folder into the application's directory on the target PC. After that, no more problems.
BTW, the DLL that was giving me issues was a 3rd-party DLL that had never had problems before on over 100 other computers... go figure.
Run Event Viewer: it'll have more information.
Probably you've attempted to run your program on a machine that doesn't have the VC redistributables installed, or you're attempting to run a debug build on a machine that doesn't have Visual Studio installed (the debug libraries aren't redistributable).
I have had the same issue with VS 2008-built debug binaries on other winxp sp3 machines.
I first tried installing the client machine with vc redist package,as it seemed sensible. Annoyingly, it didn't work.
I tried copying all the dependent dlls to the application's directory - still didn't work
After being struck over this issue for hours, I found that the latest VS builds require manifests and policies to link with the dlls. After copying them into their respective "C:\WINDOWS\WinSxS\" folders, I got it working.
The problem was caused due to the fact that the vc redist package did not install debug versions of dlls, they somehow thought its up to the programmer to figure out.