Need help with Visual Studio insanity

I'm really struggling to solve a VS problem. Some of my included header files cannot be opened inside VS even though the code compiles just fine. I'm getting an error that says windows.h is not found in the build paths. How can I add a header to the path? VS deprecated the ability to change the include paths but I also can't change them from inside the project because Handmade Hero is just a dummy solution and the option is missing from the properties page. Anybody have ideas?
Are you using VS only for debugging, not compiling? If that's so then what do you mean by "header files cannot be opened"? File -> Open -> File doesn't work? What exactly happens if you select open file menu item?

Edited by Mārtiņš Možeiko on
Correct, I am only using VS for debugging. When I right click on the #include <windows.h> there's an option to open the file. But whenever I do this, it creates an error popup that says Windows cannot find this header file in my current directory or build paths. It then gives me a list of the paths it checked for the header file.
isn't there also a button to look for it then?
There is not. The popup dialog cannot be interacted with in any way.
I've got the same result on VS2017 (installed last week). If I use VS2012 I don't have that problem.

I have several paths that contains windows.h but none that match what's in the popup.

C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\Windows.h
C:\Program Files (x86)\Windows Kits\8.0\Include\um\Windows.h
C:\Program Files (x86)\Microsoft Keyboard Layout Creator 1.4\inc\Windows.h
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Include\Windows.h

I don't know if it's related but when passing file to open to VS2017 (devenv test.exe .\lib\lib.h .\lib\abc.h ...) I often get a message that say that some of the files couldn't be opened (if I relaunch I have the message but with different files, or sometimes it works...). The files are present and I never get that problem with VS2012.
Yes, this is also my experience. If you don't have normal VS project for building, then during debugging intellisense features don't work well. And when they work then it depends on current moon phase.

The best way to debug is to open file manually and then read it or put breakpoints.
Passing /useenv as an argument to devenv seems to fix the windows.h problem for me.

Edited by Simon Anciaux on Reason: typo
Thanks! /useenv also solved this problem for me. VS Community Edition 2017 (15.5.7) on Windows 10. Like the OP, I'm only using it for debugging (Sublime for editing).

Before I was running VS like this:

Run the shortcut on my desktop that points to:
1
C:\Windows\System32\cmd.exe /k "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools\VsDevCmd.bat"


In the resulting terminal, "cd" to the dir with my built exe file, and type:

1
devenv win32_handmade.exe


I could then right click on "win32_handmade" in solution explorer, select Debug > Step into new instance, and it would bring up my source code in VS. But when I would right click on a header file include statement and click "Open document <filename...>", I would get the same error as the OP.

Running VS with this command instead makes it work:

1
devenv win32_handmade.exe /useenv


Still don't really understand why, but thanks mrmixer!
You guys are brave for even messing with VS2017. I fought that battle and lost.
/useenv has been working really well for me but I can't believe that there isn't a better way to get Visual Studio to just do what it's supposed to do in the first place. =/

Is there any way to keep the /useenv option enabled? It would be really nice to not have to pass this argument to the command line every single time I want to open VS.
There is an easier way - you create normal VS project. Then it will work as designed. Everything else is not really well/officially supported.