This seems to be a tricky question, also because it is difficult to present here all settings involved. So let me state the total picture:
I use Visual Studio 2022 to build a solution (all in x64 mode) comprising of two projects
CapopConsole
and
CapopWrap
CapopConsole is a C# Console-Project generating an exe and CapopWrap is a C++/CLI project wrapping a C++ native library called Capop. It generates a dll called CapopWrap.dll. CapopConsole has CapopWrap as dependency.
CapopWrap has three extra .lib dependencies, namely
capoplib.lib, libpredicates.lib, jsoncpp.lib
in Release mode and
capoplib.lib, libpredicates_d.lib, jsoncppd.lib
in Debug mode.
The first two of each row are from a certain project, special for me, the last one is from the well known jsoncpp project. All three libs are built with Visual Studio 2022 with the new CMake mode (no 'solutions').
Now the point is: Compiling and linking CapopWrap produces both for release and debug mode respectively a result dll, in both cases called CapopWrap.dll.
But: CapopWrap.dll from debug mode has a dependency on jsoncppd.dll whereas CapopWrap.dll from release mode has no explicit jsoncpp related dependency whatsoever (as shown with dumpbin, for example).
By symmetry one might expect that CapopWrap.dll (Release) would incur a dependency on jsoncpp.dll but this is not the case.
I would really be happy, if someone could help me find an explanation for this - my own attempts so far where fruitless.
Addendum: I do not give concrete excerpts from my .csproj and cmake files at first, because they are a bit lengthy and maybe an answer is possible without them. If not, please tell me, what you want to see concretely from my configuration files (or filesystem contents), I will edit it in then.
Related
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Debug vs. release in .NET
Debug/Release difference
What is the difference between Release and Debug modes in Visual Studio while building a project?
Debug and Release are just labels for different solution configurations. You can add others if you want. A project I once worked on had one called "Debug Internal" which was used to turn on the in-house editing features of the application. You can see this if you go to Configuration Manager... (it's on the Build menu). You can find more information on MSDN Library under Configuration Manager Dialog Box.
Each solution configuration then consists of a bunch of project configurations. Again, these are just labels, this time for a collection of settings for your project. For example, our C++ library projects have project configurations called "Debug", "Debug_Unicode", "Debug_MT", etc.
The available settings depend on what type of project you're building. For a .NET project, it's a fairly small set: #defines and a few other things. For a C++ project, you get a much bigger variety of things to tweak.
In general, though, you'll use "Debug" when you want your project to be built with the optimiser turned off, and when you want full debugging/symbol information included in your build (in the .PDB file, usually). You'll use "Release" when you want the optimiser turned on, and when you don't want full debugging information included.
Well, it depends on what language you are using, but in general they are 2 separate configurations, each with its own settings. By default, Debug includes debug information in the compiled files (allowing easy debugging) while Release usually has optimizations enabled.
As far as conditional compilation goes, they each define different symbols that can be checked in your program, but they are language-specific macros.
The main difference is when compiled in debug mode, pdb files are also created which allow debugging (so you can step through the code when its running). This however means that the code isn't optimized as much.
I'm having difficulties trying to compile an opensource framework (EmulationStation) in VS2015 on Windows. I've never used any of the tools before, apart from Visual Studio - so please forgive me if these are some obvious mistakes.
The guide says i need to do like this:
Boost (you'll need to compile yourself or get the pre-compiled binaries)
Eigen3 (header-only library)
FreeImage
FreeType2 (you'll need to compile)
SDL2
cURL (you'll need to compile or get the pre-compiled DLL version)
(Remember to copy necessary .DLLs into the same folder as the executable: probably FreeImage.dll, freetype6.dll, SDL2.dll, libcurl.dll, and zlib1.dll. Exact list depends on if you built your libraries in "static" mode or not.)
CMake (this is used for generating the Visual Studio project)
(If you don't know how to use CMake, here are some hints: run cmake-gui and point it at your EmulationStation folder. Point the "build" directory somewhere - I use EmulationStation/build. Click configure, choose "Visual Studio [year] Project", fill in red fields as they appear and keep clicking Configure (you may need to check "Advanced"), then click Generate.)
This is how my CMake looks like (it says generating done)
I get alot of compilation errors in visual studio when trying to build though:
1) Cannot open include file: 'curl/curl.h': No such file or directory (compiling source file C:\Users\retropie\Documents\GitHub\EmulationStation\es-app\src\guis\GuiMetaDataEd.cpp) emulationstation C:\Users\retropie\Documents\GitHub\EmulationStation\es-core\src\HttpReq.h
Where do I get this header file from?
2) 'round': redefinition; different exception specifications (compiling source file C:\Users\retropie\Documents\GitHub\EmulationStation\es-app\src\guis\GuiMenu.cpp) emulationstation C:\Users\retropie\Documents\GitHub\EmulationStation\es-core\src\Util.h 18
I have a lot of these errors with round. Am I missing a reference to a library?
Another screendump of some of the errors from VS2015:
Hope someone can point me in the right direction.
I am currently in de same boat as you, trying to get ES building under MSVS2015.
I am also very green, so hopefully others chime in as well.
Regarding the 'round' errors, apparently the MS compiler has no knowledge of these. For this issue, and some others, the newer ES fork by Herdinger has fixed this.
As this is currently the most active ES branch out there, and has the explicit goal of consolidating at least some of the backlog of PRs from the original Aloshi git, I would suggest you use this one.
In issue #4, there is some more information on building in recent VS versions. There is also a link for the precompiled cURL libs, including the header.
Having gone that far, I am sad to say that I still do not have a succesfull build as of yet. Compiling is no problem, however linking gives me a LNK2005 error.
Hope this helps a bit. Let me know how you fare.
I'd like to build a keyboard layout that runs on Win7 and later without using MSKLC.
I downloaded the Keyboard Layout Samples, and although it says it requires VS2013 Preview and WDK8.1 Preview, it builds using VS2012 and WDK8 after changing the "Platform Toolset" property from "WindowsApplicationForDrivers8.1" to "WindowsApplicationForDrivers8.0".
But: Checking the kbdus.dll built with Dependency Viewer reveals that it imports quite a lot of stuff from kernel32.dlland from msvcr110.dll. This is in contrast to kbdus.dll from the Windows\system32 directory, which, as one might expect, does not import anything and exports one single function.
My first question: Is it an issues that the dll built imports from msvcr110.dll?
I guess it is, as Win7 does not include this dll. (Honestly, I'm wondering how this can be, because these are official Microsoft samples.)
Tweaking around with compiler and linker settings, I managed to get rid of imports from msvcr110.dll, but the dll built still imports a lot of stuff and is quite large (> 70kB), compared to the original kbdus.dll (7kB). It's the same with x86 and x64, Debug and Release builds. I'm looking for the /compileandlinkanddonothingfancy switch.
My second question: How can these dlls be built correctly?
(Note: I found this question, but it is about WDK7. That will be what I try next, if I don't get it with WDK8.0)
I think one should pass /noentry to the linker.
I have much trouble compiling OpenCV 245 with GPU support. With some effort I managed to have cuda support up and running, but now I am stuck on opencl, here is the problem:
At some point during the compilation, the file kernels.cpp is generated, containing all kernel functions as strings. For what I understand, they are converted automatically from the .cl files with the cl2cpp.cmake script.
What I don't understand is that one file is excluded from the build: nonfree_surf.cl (which is on my disk, alongside all other .cl files) is not included, either in the visual studio project, or in the kernels.cpp that is automatically generated. This leads to an undefined error at link time.
I have tried manually adding the nonfree_surf.cl to the visual studio project. This does not change anything. In the CMakeLists.txt for ocl module, all the cl files seem to be automatically added with the line:
file(GLOB CL_FILES "${CMAKE_CURRENT_SOURCE_DIR}/src/kernels/*.cl")
I have tried manually adding nonfree_surf to CL_FILES, with no effect.
I have very little knowledge of CMake, hence I don't understand well what is going on. Can somebody give me a clue how I could find the reason of this behavior, namely:
Why are all .cl files added to my VS project, except nonfree_surf.cl ?
How can I correct this ?
Maybe I can execute cl2cpp.cmake script manually ? If so, how ?
Managed it by manually running the script:
cmake -DOUTPUT_PATH=c:/opencv/kernels2.cpp -DCL_DIR:PATH=c:/opencv/modules/ocl/src/kernels -P "c:\opencv\modules\ocl\cl2cpp.cmake"
For some reason (probably the same that makes nonfree_surf not be processed), not every necessary function are processed this way, so I juste copy-pasted the nonfree_surf string into kernels.cpp, and proceeded with the build.
If anyone needs the binaries, since they are a pain to compile, here they are:
Opencv 2.4.5 binaries compiled with VS2010 x86 (WIN32) including ocl and gpu library.
I'm running VS2010 Version 10.0.30319.1 RMTRel
I've noticed problems compiling VB.NET application. When I "rebuild" the solution it reports the build was successful. When I then click the run icon to begin debugging, then the compiler will report build errors(often related to referenced projects). I've confirmed all the projects are targeting the same framework and after an undeterministic number of times repeating the same steps, it will eventually compile. This seems consistent enough to me with other code bases to believe that it's a problem with VS. Anyone have any thoughts that might help improve my experience?
You should also check your configuration manager - probably some of projects are disabled for building in current build plan.
is this a rather large solution? If so, the order of build may be out of whack and the way to solve that is to set the build order of the projects to make sure all of the dependent projects are built first.
One common reason is circular references. You cannot do this in a pair of projects, but it can be done if you cobble together a long string of projects. The way to catch this is a dependency mapping tool with a visual representation of dependencies. You will see the items that refer back up to the top.