Build category in the properties of Visual Studio 2017 missing - visual-studio-2017

I'm currently following a tutorial on how to create conditional compilation symbols on Visual Studio, and it looks like the reason I can't figure out how to do that is because My properties window is different from what I can seem to find online.
Here is an image taken from the tutorial, showing how to create those symbols:
And here is what my properties list looks like:
I've been looking seemingly everywhere in options but can't find how to either turn on the build (and build events) buttons, or where to set up some conditional compilation symbols.
Would anyone know how to fix my issue?
Thank you!

Alright, I ended up finding an answer myself, so I'm going to post it here just in case others end up running into the same issue.
So, for an unknown reason (unknown to me at least), my conditional compilation symbols are under the "Compilation Constants" category.
It can be accessed using the following path:
Project → Project Properties → Compile → Advanced Compile Options → Custom Constants (see image below for more information)

Related

openCV in visual studio 2012

I am getting an error [I get an error opencv_core242.dll is missing] when trying to compile a test program from http://karanjthakkar.wordpress.com/2012/11/21/usin-opencv-2-4-2-with-visual-studio-2012-on-windows-7-64-bit/.
I tried to add the specified information in something called a environment variable, however I do not know if I am doing it correctly. Can anyone clearly state step-by-step what I am supposed to do to add as the value? I put the paths to the directories that I need but it doesn't seem to resolve this error when I try to build the program.
#Code Head has got one of the answer.
Or you can just copy all the dll's in opencv/build/vc11/bin into your program directory.
I know this is really an ugly solution but this surely works for a starter. At least I myself find it really useful when I first started using OpenCV.
Here's what you need to do:
RightClick your project in "Solution Explorer"
Click Properties
Navigate to "Configuration Properties -> Debugging"
In "Local Windows Debugger -> Environment" Write:
Path=$(Path);C:\path_to_opencv\build\x86\vc11\bin
or (if compiling 64 bit):
Path=$(Path);C:\path_to_opencv\build\x64\vc11\bin

Enabling/disabling SAFESEH in VC11?

I created a new solution for zlib 1.2.7, set it up as a static library, added the necessary headers and source files from ./zlib/contrib/minizip and got it to compile just fine. I then linked it against libpng (also as a static lib), which also compiles fine. Then, I linked libpng to my graphics engine project (also a static library)... still no errors.
But as soon as I link my main project to my graphics engine, I get several LNK2026 errors regarding crc32.obj, deflate.obj, inflate.obj, d3dxplane.obj, d3dxvec4.obj and other zlib/directx related modules. It's telling me that they are coming from my graphics engine lib, so I've decided to fix this by adding /SAFESEH:NO to my linker flags for the corresponding projects.
NOTE: I should probably state that all projects are set to target x86, NOT x64.
The problem, however, is now I'm getting:
warning LNK4044: unrecognized option '/SAFESEH'; ignored which results in the same LINK2026 errors in my main project.
If I open up a visual studio command prompt and type LINK /? it confirms that /SAFESEH is a valid linker option. I get the same error when I use /SAFESEH (without the ':NO'), and if I omit it entirely then my main project simply refuses build.
What's going on here? How do I get around this?
by adding /SAFESH:NO to my linker flags
Well, you mis-spelled it. Maybe in your question, maybe in the linker settings, the kind of coincidence that tends to explain why something that should work doesn't work.
It is available without having to type it in, do favor doing it that way. Project + Properties, Linker, Advanced, scroll down the right panel, "Image has Safe Exception Handlers" setting. Use the combobox to select No.
A quick google shows this indicates you need to recompile the offending modules with appropriate compiler settings.
Note that this flag is only works for x86 targets. If you're targeting 64-bit, you'll get this error regardless.
Also, from http://msdn.microsoft.com/en-us/library/9a89h429(v=vs.80).aspx, which may be relevant:
The most common reason for the linker not to be able to produce an
image is because one or more of the input files (modules) to the
linker was not compatible with the safe exception handlers feature. A
common reason for a module to not be compatible with safe exception
handlers is because it was created with a compiler from a previous
version of Visual C++.
It would be helpful if you provided version numbers of your compiler, and how your copy of zlib was built (did you build it yourself, and if so, with the same compiler?).
In Visual Studio 2017
Right click on Project -> Properties -> Configuration Properties -> Linker -> All Options ->
Image Has Safe Exception Handlers = No (/SAFESEH:NO)

Eclipse C/C++ Shows Errors but Compiles?

So I am building some Arduino code in eclipse, as described in Your Second Arduino Project, but every time I use an Arduino library, such as Serial, Eclipse underlines my function names, claiming they cannot be resolved. However, the code actually compiles, so I'm kind of at a loss as to why Eclipse thinks the functions are missing. If anyone has any idea on how to solve this problem it would be appreciated. Thanks beforehand.
EDIT: I should have been more specific, Eclipse underlines the METHODS inside the Arduino libraries. So if I use Serial.println("hello");, it underlines println() and claims it cannot be resolved. Then it compiles just fine and the method works when uploaded to the arduino board.
EDIT2: I found my error, turns out I was trying to use some C++ functions in a C file, and eclipse didn't like it; I renamed to .cpp and all the red disappeared ;) Thanks for your help!
Eclipse may or may not be pulling the paths to index from your build setup, depending on the configuration. Most likely, it is not...it's building correctly because your build setup is just fine, and you can probably build by hand.
The CDT indexer (which is the engine for deciding where all those pretty underlines, as well as code completion, F3 declaration jumping, etc comes from) isn't smart enough in a lot of cases to parse out your Makefiles and know where to look for headers and source. You need to tell Eclipse that information manually.
Go to Project Properties -> C/C++ General -> Paths and Symbols.
The amount of work you need to put into this can vary greatly, depending on your environment. If this external library is the only thing giving you headaches, then you probably just need to add the paths for that library and reindex:
Right-click on the project and select Index -> Rebuild
For starters, what color is the underline? This makes a difference, as yellow means it's a warning, and red means it's an error (critical, will not build in most circumstances).
Second, you need to look at the "Problems" tab to see if there are actual errors. If there is nothing there, then it did indeed compile correctly.
Now, back to the original question. Depending on the type of project you are building, this type of behavior is not that uncommon. Eclipse seems to do a poor job of indexing certain projects. When you run "make all" from the command line (which is effectively what Eclipse does during build) it is likely resolving all of your code and building it just fine.
However, Eclipse uses a different, separate tool for indexing all of your source code and resolving variable/function definitions and declarations. This is literally a case of the left hand not knowing what the right hand is doing.
The solution below worked for me:
Click to your project using right click. Then: Properties -> C/C++ General -> Paths and Symbols -> Symbols -> GNU C++.
Almost for sure there are no symbols at all if you have this problem. Add symbol "__cplusplus" with value "201402L"
After this:
Right click on Project -> Index -> Rebuild
You are done.
I had include folders in
Project Properties -> C/C++ General -> Paths and Symbols -> Includes
When I removed those, the red underlines went away, i.e. the build and the IDE where in sync.
When resolving symbols, CDT indexer seems to consider all header files irrespectively of which ones are actually included in the compilation unit. There is a corresponding bug report filed with Eclipse Bugzilla: https://bugs.eclipse.org/bugs/show_bug.cgi?id=439553
In my case the problem was due to adding "-std=c++17" flag in the language standard field in the project properties under the compile dialect. After that the build was passing with errors, but the program was running fine. So the trick of Index>Rebuild resolved everything.
If you changed something in the configurations, (example, editing in *.cproject file with notepad++) , the below options helps.
Build Configurations --> Clean All and then Index --> Rebuild
I had the same problem.
Index -> Rebuild didn't help.
When I added line #include <avr/iom1280.h> in main.cpp and made Index -> Rebuild underlines dissapeared.
Then I deleted line #include <avr/iom1280.h> and project still without inderlines.
Replace iom1280.h with name of your controller. Look at the "avr\include\avr\" folder for available names
Eclipse does not work as well with C++ as it does with Java, but it should warn you about issues once you press "Rebuild" in the menu bar.
Try that, and see if it resolves your problem.

Visual Studio No Symbols have been loaded for this document

I am having some trouble debugging a visual studio 2008 C++ project. When I start running it in debug, the breakpoints are disabled with the message
The Breakpoint will not be hit. No Symbols have been loaded for this
document.
I have tried cleaning and rebuilding, but this doesn't make a difference.
I also tried looking in Debug->Windows->Modules. If I right click on the module I am trying to debug and press Symbol load information it brings up a list of places it has tried to load the symbols from. The first in the list is correct and the file exists, but next to it is this error
C:\path\to\my\symbol\Debug\MyProject.pdb: Unknown symbol handler for
error
Does anyone know what causes this or how to fix it?
First of all, it is possible that some of your modules won't show in the module window, because some of them may be loaded dynamically (only as needed).
You might want to check in your project properties under Linker > Debugging > Generate Program Database File and Generate Debug Info. Be sure these two are set properly.
Also, check if C/C++ > General > Debug Information Format is set to Program Database for Edit And Continue (/ZI) or something similar.
I know you mentioned that your symbol file exists, but checking what I just mentioned will ensure you have the right version of your symbol in the right place.
Finally, check if all your project and files in your solution are set to compile as Debug and not Release or something else, because no symbols will be generated (hence none will be loaded) for this project / file.
Hope this helps a bit.
In my case, the problem was solved by checking "Use Managed Compatibility Mode" in Tools / Options / Debugging / General.
In case anyone has this problem when using 'Attach to process', the answer to this question solved it for me:
Visual Studio is not loading modules when attaching to process
Specifically, switching to 'Native code' in the 'Attach to' options instead of 'Auto'.
I have managed to solve this by copying my source sideways and checking out a completely clean copy. I assume it was some setting stored in the projects .suo file.
Go to the "Properties" for the website that would use that dll for debugging and then select "Native Code" in the "Debuggers" section below:
There could be a problem with the mspdbsrv.exe process. Try killing it and start debugger again.
For me the fix was in restarting the Visual Studio :) As simple as that. Nothing else helped - tried to Clean (even deleted all files in the Debug folder), checked settings, even killed the mspdbsrv.exe process, but only VS restart did the trick.
In the Modules window you can right click and add your Debug output folder to folders where your system looks for symbol files. Also, the thing that worked for me was deleting all the output files manually, Clean won't do it every time and that's why even though the .pdb file is generated, it doesn't correspond to your output files, thus not loading symbols from it.
Delete all files in the bin and obj folders. Then build the solution again. If your problem was like mine, it seemed like VS was loading an older version of a specific unknown file that rebuilding the solution/project would not replace. Make sure to make a copy of your solution/project before trying this. Good Luck!
Make a copy of your "Debug" folder within your project's folder, then delete every file in the original "Debug" folder. As additional measure if you had your visual studio already running with your project loaded, close it after deleting Debug's contain and reopen it before re-build the whole project, theoretically this action will create new copy of symbol files and the rest needed to debug your code.
I found out this problem occurred to me when I moved my files to other computer and try to compile and debug my code from there, although all folder and drive names were the same, some how the IDE was unable to use the previously created symbol files.
Hope this work around works for some one else !.
VS2015 C++
I ran into the same problem after cancelling the loading of symbols whilst attempting to debug my application in VS2015. After this, VS2015 refused to load the symbols for the project I was interested in (multiple sub projects in a solution with C# calling C++ DLLs). Solutions above did not work for me, but this did.
For Visual Studio 2015 (C++):
Right click on your project that your break point is in and select
properties Expand C/C++
Select General under C/C++
Change the Debug Information Format to any other option
Click Apply
Change the Debug Information Format back to its default "Program
Database for Edit And Continue (/ZI) (or whatever you prefer)
Click Apply
Now rebuild your project
Hope this helps.
Alan M
1) Right click on the project you want to debug.
2) Select [Properties]
3) Select the [Build] tab
4) Make sure [Define DEBUG constant] and [Define TRACE constant] are checked
5) Click the [Advanced] button at the bottom of the Build tabpage
Make sure that [Debug Info:] is set to [full]
6) Click [OK]
7) Rebuild the project
In my case, "use library dependency inputs" in "linker->general"should be set to yes, then the problem is solved.
None of the above helped me...
At the end I changed from Debug\X64 to Debug\win32, this helped, probably it's some configuration which isn't the same in both. Maybe this will help as a
workaround for someone...
Hope that could help anyone.
I'm debugging a WIA driver, and came across this similar problem.
I noticed this log :
DLL named C:\Windows\System32\WIA\wiadriverex.dll cannot be loaded (LoadLibraryEx returned 0x0000007E). Make sure the driver is installed correctly
Then I realized that it is due to DLL dependency. Then I copied required DLLs to System32, the problem is gone. Pay attention, copy to System32, or it won't work for me.
It helped in my case:
Debug -> Attach to process
Scroll down to w3wp.exe
Check "Show processes from all users
After refresh scroll again to w3wp.exe
Select new one with type x64, Managed (Native compilation)
Try disabling /GL option if it has been enabled in C/C++ / General / Optimization / Whole program optimization.
Initially, I had no issue with debugging my program but after tweaking here and there the issue that OP says began to arise.
The module and its symbols were loaded and nothing in this guide seemed to correspond to my problem. Turning /Zi to /Zl also didn't help.
I'm not sure why, but, it's sort of a compiler behavior I haven't been experienced before. FYI, /GL option is not a default in the C++ projects in VS2017.
In my case, the error was due to the fact that part of the code was connected as an external library. In order for debug process to work also when going into the code of the external library, it was necessary to add not only its headers, but also the implementation files - folder Source Files of Solution Explorer.
In my case it was debugger type.
I used remote windows debugger, changing it to local solved an issue.
Debugger options:

Visual Studio 2005 Ignores Preprocessor directives during compile

We just got a new developer and I'm trying to set him up with Dev Studio 2005 (The version we all use at this office), and we're running into a weird problem that I've never seen before.
I have some code that works perfectly on my system, and he can't seem to get it compiled. We've tracked the issue down to his copy of dev studio ignoring the preprocessor directives.
For example, in the project properties under C/C++|Preprocessor|Preprocessor Directives, I add DEFINE_ME. Which should translate to a /D"DEFINE_ME" for the compiler. And it does in my development environment, but it doesn't on his.
I verified that when he checks out the code from the source repository, that he has the same version of the code I do. And if I look in his Project Properties, all of the directives are there. For some reason they're just not getting passed down to the compiler.
Any Ideas?
I recently ran into the same symptom with VS2005. Ultimately I was able to resolve it by explicitly adding my preprocessor defines via the Command Line - Additional options dialog:
Configuration Properties -> C/C++ -> Command Line
When I added '/DPROPERTY' there it was recognized at compile time, whereas adding it under 'Preprocessor -> Preprocessor Definitions' did nothing. Oddly the Command Line dialog did show that Visual Studio was adding the property to the command line, albeit in the form '/D "PROPERTY"'.
Unfortunately schedule pressure being what it is I have not been able to dig into the issue deep enough to figure out what the underlying issue was/is, nor why it seems to work out of the box for some of our projects but not others. Nonetheless the workaround above is worth a shot if you're having this symptom.
Also, credit where credit is due: the idea came from this thread.
Make sure that the project configuration which is being built in the selected solution configuration is the same as the one you're configuring the properties for, and/or that you're configuring the properties for all project configurations. A common problem with new VS installations is that the current active solution configuration is system-specific, and may default to something not matching yours (eg: Release vs Debug).
You can see the project config in the build output, and/or check it in the Configuration Manager.