I am writing a C++ dll application via JNI interface to call Java program from C++. I am using Java8, C++, Visual Studio 2010 professional and Windows 7. I am currently setting Configuration as ACtive(Debug), platform as Active(x64).
I noticed that if I select Active(x64) as platform, then there's no complains from VS. If I change it to Win32, it will complains about "Cannot open jni.h". If I change the configuration to release, platform as either x64 or Wind32, it will complain about "Cannot open jni.h" as well. Why is this? Can anyone explain?
I can build solution and produce dll using configuration=debug and platform=x64. I can then call this dll from my other c++ projects no problem. Do I have to change the configuration to release to release the dll to the system? What is the purpose of release and debug?
If anyone have documentation about solution configuration, please share as well.
Thank you.
For the include issue, make sure that your project configuration is pointing to the directory where jni.h exists. That is basically all you need to do.
As to debug and release, the release version is the one you must build if you plan to distribute your JNI DLL to third parties (for example, your customers). The difference is that the release version will use the "release" Microsoft runtime libraries, which can be distributed to any PC, free of charge.
It is not legal (as per the Microsoft license agreement) to distribute debug versions of your DLL since the debug version uses the Microsoft Debug runtime libraries. These debug libraries are only available to persons who have a valid Visual Studio 2010 installation.
Related
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've got a problem with several VC++ DLLs, which I should include into my .NET/C# project. One VC++ DLL is a C++/CLI DLL, which I use as public interface from my .NET project. The other DLLs are written in native C++. I have no access to the source of the VC++ DLLs, I just have to use them.
I've made a .NET test project and referenced the C++/CLI DLL. No problem, compiler is lucky, great. There's just one problem: when I start the EXE of the .NET program, I get errors about the C++ DLLs because of missing VC++ core DLLs.
sxstrace shows the following (shortened):
INFO: Reference: Microsoft.VC80.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.6195"
INFO: Reference: Microsoft.VC80.OpenMP,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.6195"
INFO: Resolving reference Microsoft.VC80.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.6195"
...
ERROR: Cannot resolve reference Microsoft.VC80.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.6195".
Now I'm no fool and tried several things. I've read much about WinSxS to get a deeper understanding about what's going on.
Now I'm at the point, where it's getting weired for me. The system where I want to execute the program has the VC++ Redistributable package in the current version 8.0.50727.762 (SP1) installed. I know that there's a policy file for Microsoft.VC80.CRT in winsxs that redirects all versions of this assembly to the current version 8.0.50727.762 (that's the solution for the problem at http://blogs.msdn.com/b/nikolad/archive/2007/03/29/a-solution-to-two-references-to-different-versions-of-crt-mfc-atl-in-one-application-manifest-file.aspx).
But as the error above says, this policy file doesn't seem to work or isn't taken into account. The system just wants to find the 8.0.50727.6195 version of the assembly.
Now that's the first question: what's the problem here? After I got this figured out, I could solve the initial problem...
Ok, now it works - thanks for your help.
I figured out two problems that had to be solved:
1) I had to install the "Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package MFC Security Update", which deploys version 8.0.50727.6195 of the VC++ assemblies. This update was hard to find at the Microsoft servers, so here's the link: http://www.microsoft.com/download/en/details.aspx?id=26347
Normally you only find the 8.0.50727.762 version ("Visual C++ 2005 Service Pack 1 Redistributable Package), which is outdated. Since the C++ DLLs were compiled against 6195, installing the update solved the first problem.
2) While the C++/CLI DLL was compiled in Release mode, the native C++ DLLs below had been delivered in Debug mode. Now the Microsoft license agreement prohibits deploying the VC++ Debug DLLs and the VC++ Redist Packages don't include the VC++ Debug DLLs.
http://msdn.microsoft.com/en-us/library/aa985618.aspx says:
Debug versions of an application are not redistributable and none of the debug versions of the various Visual C++ dynamic-link libraries (DLLs) are redistributable.
Solution: the developers of the native C++ DLLs gave me a release version and everything works fine...
When I try to open released .exe file (which I wrote in Visual Studio 2008) in VMWare Workstation 6.5 with Windows Server 2008 32bit OS, got "The application has failed to start because its side-by-side configuration is incorrect." error all time even if the code is;
#include <stdio.h>
int main ()
{
printf ("HELLO\n");
return 0;
}
Is anyone faced that king of problem or does know how to cope with it?
You probably forgot to deploy the runtime support DLLs or copied the Debug build of your program. For a small program like this without DLLs that export C++ classes or pointers it is better to link the static version of the CRT. Project + Properties, C/C++, Code Generation, /MTd. Repeat for the Release configuration, now choose /MT.
It has nothing to do with VMWare -- it has to do with not having the correct side-by-side assemblies for the C runtime installed. You need to know which ones you require, and then install the runtime. You can also control it with a manifest.
There is some info here
http://en.wikipedia.org/wiki/Side-by-side_assembly
One easy way (for C/C++ programs) to get around this is to change to linking to the C-runtime statically. Go to your project properties, then Code Generation, and choose static linking for the C Runtime. Then you won't have a dependency on the runtime dlls. All libraries you might be using need to be linked this way for it to work.
I generally get this error if the C/C++ runtime that the program was built with was not installed in the VM. You can download the CRT for Visual Studio 2008 SP1 at Microsoft's website. Make sure to download the correct version of the CRT based on the versions of Visual Studio used to build the app.
I've got a minimal app I just created, using VS 2008 SP1 on Vista x64. Its a Console app, created with the wizard, no MFC or anything, I'm building it in 64bit.
When I run the debug exe, on my development box, by pressing F5 in Visual Studio 2008, I get this error:
TestApp.exe - Unable To Locate Component
This application has failed to start because MSVCR90.dll was not found.
Re-installing the application may fix this problem.
OK
I don't get this error when I run the release exe, it works as expected.
This problem started when I added some include dependencies on iostream and fstream and started calling some winsock API calls.
Any suggestions?
UPDATE: I copied msvcr90.dll (not msvcrd90.dll) into the correct folder, and now I get a different error:
Microsoft Visual C++ Runtime Library
Runtime Error!
Program: [snip]...
R6034
An application has made an attempt to load the C runtime library incorrectly.
Please contact the application's support team for more information.
OK
Alex
You application is using the DLL CRT runtime. The machine you want to run it on requires the installation of the debug CRT runtime dll's (which is a pain in the ass...). I think the better solution is to change the compile options to use the static linked CRT runtime (that means the runtime is linked into your application instead of using the DLL version).
In visual studio go into the Properites for your project then select the Configuration Properties / C++ / Code Generation and change the "Runtime Library" from "multi-threaded debug dll" to "multi-threaded debug".
You may like to do the same for the release build as well because some versions of the OS will not come with the V9 release CRT libraries pre-installed, or you can include the v9 release crt dll as part of your install.
How are you running the release exe (Ctrl+F5 in the IDE)? You should set the Runtime Library to the same thing you are setting the release exe.
Are you linking your debug mode program to a release mode library? You mention this error in a comment:
Error 13 error LNK2005: memmove already defined in LIBCMTD.lib(memcpy.obj) MSVCRT.lib DataEngineSocketsAPI
What that looks like to me is you have a library named DataEngineSocketsAPI that links to MSVCRT.lib, which defines memmove(). But, your exe links to libcmtd.lib, which also defines a different (debug mode) version of memmove().
Third-party (e.g. your own) libraries must have debug and release versions too, and you must use the one appropriate to the mode you're building your exe for.
The Debug exe is linked to the headers for the debug runtime library, MSVCR90D.dll. You need to make sure that dll is in the path. Static linking is, as Shane says, a viable option, but the typical solution is to deploy the dependant dlls with the exe. Statically linking everything leads to bloated exes and lots of duplicated copies of runtime libraries.
Seeing your edit, the problem is certainly the msvcr90d.dll, but it needs to be deployed correctly in the WinSXS folder. You might be able to re-install the service pack for VS 2008 and get it to redeploy.
Thanks again for all the help with this. It turns out I'd just made a mistake and not noticed that a library I was using was statically linked against a different version of the MSVC runtime. That was causing on end of problems.
See this link
http://www.insidercoding.com/post/2008/07/21/Debugging-issues-with-MSVCR90DLL.aspx
You need (for debug mode only) to ignore on the link input tab MSVCRT; MSVCR90; as you want to be using the debug version of the CRT.
I can confirm this problem: letting Visual Studio 2008
create the project (Visual C++/Win32 Console Application)
and pressing F5 will display that error.
There is a simple solution:
Turn incremental linking off. HOWTO: open properties page
for the project. Set Configuration
Properties/Linker/General/Enable Incremental Linking to "No
(INCREMENTAL:NO)".
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