Home/ Questions/Q 637985
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T20:41:00+00:00

I’m C++ dev migrating to visual 2010 c++ from vim/g++. Here blog I’ve read

  • 0

I’m C++ dev migrating to visual 2010 c++ from vim/g++. Here blog I’ve read that VC++ directories are no more and that I should use property pages in vs 2010 but I don’t know how… Here is what I need to do. I have w solution (50 projects strong) and all of them use boost, pthreads, xercesc and few other libs. I have env variables that point to those libs on my hard drive. How can I tell VS to use them as additional include paths? Again, it’s 2010 version so no vs per solution setup available. I do not want to set it manually in every project.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The answer to your question is also in the blog that you linked to, but it’s mentined in a kind of round about way:

    If you open up the Property Manager view to see the property sheets associated with your project, you’ll see that one of the property sheets is named Microsoft.Cpp.Win32.User. This property sheet is actually stored in LocalAppData, just as VCComponents.dat file was, in the directory %LocalAppData%\Microsoft\VisualStudio\10.0. Using the property editor on the property sheet (just right-click on this property sheet node and select Properties…), you can see that you are able to make edits directly to this file. Since all projects, by default, import this property sheet, you are effectively editing the VC++ directories in the same way you were able to do before.

    The key is that you get to the VC++ Directories property through the “Property Manager” windows (open it via the View/”Property Manager” menu selection). The VC++ Directories setting is in the “Microsoft.Cpp.Win32.user” property sheet – that edits the global setting, so you should only have to do it once.

    There seem to be quite a few people who dislike this change; I think that’s because it’s less discoverable and obvious than how the setting was managed before. The trade-off is that it’s more flexible and integrates into the MSBuild architecture better, and once you do know about it it’s just as easy to change as before (it’s just harder to find, particularly if you’re used to the old place).

    • 0