Does anybody know how to do coverage of an C++/CLI class using NCover?
NCover only measures coverage of an assembly if it finds a matching .pdb file.
However, my C++/CLI project does not output a .pdb file.
If I go to "Visual Studio -> Configuration Properties -> C/C++ -> Output Files -> Program Database File Name" and set it to "MyDll.pdb" it actually outputs a file called "MyDLL.idb"!?
Yeah, confuzzling setting. It is actually a linker setting: Linker, Debugging, Generate Program Database File. Make sense if you think about it, only after linking are all object files combined and can debug info be created.
Not sure why you'd have to jump through this hoop, the default settings in the Debug configuration ensure that a .pdb file is created. Ought to be good enough for NCover, I'd imagine.
Are you compiling a Release build, or Debug build? As Hans mentioned, the default settings for Debug will generate a .pdb that NCover can use.
Related
I have the following problem:
I need to build a static library (.lib) that can be provided with other source code in such a way that the project can be linked with it. However when I build the library in release mode, the build generates .pdb files and has full paths to them baked into the final .lib itself, making it unusable.
I don't necessarily care if it generates .pdb or not, but what setting should I change in the .vcxproj to make sure that the final release .lib doesn't require (or insert) absolute paths for those .pdbs?
I was trying to install a neural networks toolbox called CarlSim using visual studio 2012, in which they use gtest in their code. I try to install gtest by downloading it online and build using gtest.sln file. It gives me two warnings. I guess these two warnings are the reason for this error. But I don't know how to solve this. The gtest seems only can build gtestd.lib.
Below is the error during install of the neural network toolbox
Error 2 error LNK1104: cannot open file 'gtest.lib' C:\Users\Dukerama\Desktop\CarlSim\carlsim\test\LINK carlsim_tests
Below are the warnings of the gest.
1>------ Rebuild All started: Project: gtest, Configuration: Debug Win32 ------
1> gtest-all.cc
1>C:\Program Files(x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppBuild.targets(1299,5): warning MSB8012: TargetPath(C:\Users\Dukerama\Desktop\gtest\gtest- 1.6.0\msvc\gtest/Debug\gtest.lib) does not match the Library's OutputFile property value (C:\Users\Dukerama\Desktop\gtest\gtest-1.6.0\msvc\gtest\Debug\gtestd.lib). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Lib.OutputFile).
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppBuild.targets(1301,5): warning MSB8012: TargetName(gtest) does not match the Library's OutputFile property value (gtestd). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Lib.OutputFile).
1> gtest.vcxproj -> C:\Users\Dukerama\Desktop\gtest\gtest-1.6.0\msvc\gtest/Debug\gtest.lib
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========
Output from build command in VS you have posted suggests that there are inconsistencies between certain values in VS project properties for gtest (located in 'Configuration Properties -> General' and in 'Configuration Properties -> Librarian -> General'). However, output also suggests that the gtest library is built at location:
C:\Users\Dukerama\Desktop\gtest\gtest-1.6.0\msvc\gtest/Debug\gtest.lib
You should take this file and place it in directory where CarlSim toolbox expects to find the gtest library. You can find this out in the VS project properties for CarlSim ('Configuration Properties -> Linker -> General -> AdditionalLibraryDirectories').
P.S.
Make sure that both gtest and CarlSim link to the same runtime library, or you'll get more linker errors. You can inspect the runtime library in their VS project properties at 'Configuration Properties -> C/C++ -> Code Generation -> Runtime Library'.
I had the same problem.
Unfortunately, the proposed solution didn't help me.
In my case, the build worked properly on my PC, but it gave the error on a collegue's PC.
We solved it moving the project in a new location with a shorter path.
Here is my setup:
Windows 7 x64, MingW, Msys, CMake, Freescale Kinetis SDK, Code::Blocks
I'm trying to get the project settings established by CMake into a proper Code::Blocks project. When I modify the provided build_debug.bat file with -G "CodeBlocks - Unix Makefiles", it indeed produces a .cbp file, as well as the normal Makefile (and it builds the project). However when I open this .cbp file in Code::Blocks, it basically just points to the Makefile, and building the project just runs make on the Makefile.
If I deselect "This is a custom Makefile" from Project Options, and add a source file to the project tree like a normal IDE, it doesn't get built correctly, ie the include files, libraries, linker stuff, compile options, etc., are not imported into the project itself. It seems the project is basically just a holder for the Makefile, so there is not much benefit to this as an IDE.
Of course if I add the source file to the original CMakeLists.txt which is part of the distribution, and rerun cmake (via the build_debug.bat file), then it works fine.
So is there any way to get a "real" IDE configuration out of CMake? I'm guessing the answer is No, since a "real" IDE configuration is a static thing, and a Makefile is a general (Turing complete) program, so there is no way in general to create this automatically, although I suspect for 99% of cases you're just specifying include directories, lib files, and compiler options, so no general programmability is truly needed.
I can probably try to figure out where the deeply obscured gcc calls are getting their include files from, what libs are being linked in, and what compile options are being used, and add all that stuff manually into a native Code::Blocks project, but this seems to defeat the purpose of having this already done for me by the package providers, and gets very tedious when building for a different CPU or development board.
Thanks
"Real configuration" is a CMakeLists.txt, and you need to modify CMakeLists when you editing project configuration. Both makefiles and IDE settings generated by CMake are temporary and you should not edit them.
Some IDEs are able to manage project configuration directly in the CMakeLists.txt
IDE: VS2005
Say I am using Poco library and the executable needs below dlls. I have to put them in same directory where the executable is.
msjava.dll
msvcp80.dll
msvcr80.dll
PocoFoundation.dll
PocoNet.dll
Is there any way that can build a dll-free executable? Thanks.
They don't have to be in the same directory. They can be in another directory if your PATH variables includes the directory they are in.
It looks like the Poco libraries can be downloaded as source, so you should be able to build them as static libraries and make a stand alone executable.
Update
For the msvc DLL's, you can build against static libraries. Bring up the properties of your project, go to C/C++, Code Generation and modify "Runtime Library". Make sure to choose a library other then "Multi-threaded DLL" or "Multi-threaded Debug DLL." You will also want to make sure you do that for the Poco libraries as well.
I got a .h file, two .lib files, a .dll file and a tiny test project from a hardware vendor to talk to their hardware.
Compiling and running their test project works just fine. Noteworthy: they don't use the .dll. I can throw the dll-directory and all of it's content away, everything works just fine.
To start things off I simply copied the communication parts of their code (connect, disconnect and send a command) into my project. This is actually all that you can do. I have included the .h file and pointed to the directory containing the .lib files. Just like in the tiny test project. It all compiles, but when I try to run the project complains that it is missing the .dll file.
Can anybody explain what is happening? How are libs and dlls supposed to work?
All of this is on windows, VS2005. I compared the .vcproj files and could not find any significant differences.
The test project is statically linked - the lib is included in the exe.
Your project is dynamically linked - the dll is referenced and therefore needed at runtime.
See this Stack Overflow question for more information.
Basically the answer depends on whether you are going to use static or dynamic linking for your executable.
With static linking, you need the .h and .lib files but not the .dll files to compile and link. Your executable will be larger but you won't need any of the .h/.lib/.dll files during runtime.
With dynamic linking, you just need the .h files to compile and link. Your executable will be smaller but you will need one or both of the .dll files during runtime.
For a more detailed treatment of this from the Visual Studio perspective, check out http://msdn.microsoft.com/en-us/library/1ez7dh12.aspx -
"Dynamic linking differs from static linking in that it allows an executable module (either a .dll or .exe file) to include only the information needed at run time to locate the executable code for a DLL function. In static linking, the linker gets all of the referenced functions from the static link library and places it with your code into your executable."