locked
Include and Library paths.

    Question

  • Hi All.

    I just installed VS2010 to make a test-build of our VC project and i have a problem.
    How do i set the LIBPATH and INCLUDE directories inside IDE ??
    I'm used to have a tab under "Tools/Options" dialog, but i can't find under this beta 1.

    I tried also to import them from an export of VS2008 settings, but it appears to be not working,
    at least ai can't see any effect.

    Where am i wrong  ??

    Thanks in advance for your help.

    Rod
    Wednesday, May 20, 2009 9:25 AM

Answers

  • Hello Rod,

    I found it in project settings - right click on the project > properties > VC++ Directories in the left pane. If you want to specify them only once and use in multiple projects, then a property sheet will probably do nicely.
    Wednesday, May 20, 2009 8:39 PM
  • You'll also note that a property sheet called Microsoft.Cpp.$(Platform).user.props was already added to your projects. This property sheet is the equivalent of the Tools/Options/VCDirs as it sits in your %USERPROFILE% folder and is by default imported in all the C++ projects. Changing VC Directories in this property sheets will impact all C++ projects.

    Also, during migration from VS2008, all your Tools>Options>VCDirectories options should automatically be migrated to these property sheets. Let us know if that's not the case.

    Thanks,
    Marian Luparu
    Visual C++
    Wednesday, May 27, 2009 4:33 AM
    Moderator
  • I found them in my Local Settings\Application Data\Microsoft\VisualStudio\10.0.
    Saturday, May 30, 2009 1:54 PM

All replies

  • Hello Rod,

    I found it in project settings - right click on the project > properties > VC++ Directories in the left pane. If you want to specify them only once and use in multiple projects, then a property sheet will probably do nicely.
    Wednesday, May 20, 2009 8:39 PM
  • Hi Boris.

    Thanks a lot.

    That's was exactly what i was looking for . . .

    Bye.

    Rod
    Thursday, May 21, 2009 8:52 AM
  • You'll also note that a property sheet called Microsoft.Cpp.$(Platform).user.props was already added to your projects. This property sheet is the equivalent of the Tools/Options/VCDirs as it sits in your %USERPROFILE% folder and is by default imported in all the C++ projects. Changing VC Directories in this property sheets will impact all C++ projects.

    Also, during migration from VS2008, all your Tools>Options>VCDirectories options should automatically be migrated to these property sheets. Let us know if that's not the case.

    Thanks,
    Marian Luparu
    Visual C++
    Wednesday, May 27, 2009 4:33 AM
    Moderator
  • You'll also note that a property sheet called Microsoft.Cpp.$(Platform).user.props was already added to your projects. This property sheet is the equivalent of the Tools/Options/VCDirs as it sits in your %USERPROFILE% folder and is by default imported in all the C++ projects. Changing VC Directories in this property sheets will impact all C++ projects.

    Also, during migration from VS2008, all your Tools>Options>VCDirectories options should automatically be migrated to these property sheets. Let us know if that's not the case.

    Thanks,
    Marian Luparu
    Visual C++
    Ok, I'm probably blind and stupid, but what is the exact path for this file? I can't find it in %USERPROFILE%, or under Documents\VS2k10. And the property manager window in VS refuses to show a path to the file.
    Saturday, May 30, 2009 1:40 PM
  • I found them in my Local Settings\Application Data\Microsoft\VisualStudio\10.0.
    Saturday, May 30, 2009 1:54 PM
  • This property sheet is the equivalent of the Tools/Options/VCDirs
    If that's the case then I think it would be a good idea to have the old menu item location (tools-options-projects and solutions-vc directories) just edit that directly  (obviously you can still do the new way as well by going into the property manager), or at least have a pointer to where you need to go to change those directories.
    Thursday, June 04, 2009 11:56 AM
  • There are a couple of problems with this approach: 

    1. The location/context of this dialog box (i.e. right-clicking on a project) implies that these settings are project-local. If they're machine-global, this needs to be made much clearer. Per-project directory settings are a good idea, but they shouldn't replace per-machine directory settings. What if two machines have a required SDK installed in different locations? Best practice would probably be to specify this via an environment variable, but not everyone's going to do this.

    1a. In fact, I've just checked, and that dialog definitely looks like it's project-local (the project name is in the caption). If it is, that breaks the per-machine semantics that we require, and if it's not, then it's in the wrong place.

    2. The settings in C:\Documents and Settings\rogerl\Local Settings\Application Data\Microsoft\VisualStudio\10.0\Microsoft.Cpp.Win32.User.Props were correctly imported from my VS2008 VCComponents.dat file, but they're being ignored. 

    • Edited by Roger Lipscombe Thursday, June 11, 2009 7:45 AM formatting, hopefully
    Thursday, June 11, 2009 7:41 AM
  • Roger - some good observations. I'll say that the VC Directories issue is a classic one of "works great for simple cases" and "falls apart for rich/large/complex cases" - and thus getting the UI right is tricky indeed.

    Let me just remark on a couple of things you said.

    1. The UI is correct, but probably confusing when compared against Tools->Options. The VC system supports property sheets (View->(Other Windows)->Property Manager), which allows for property values to be inherited into a project from other files. Therefore when you right-click on a project and bring up the properties, you are seeing both inherited (non-bold) and locally set (bold) values. This isn't obvious, but it is the same as Orcas...if that is a defense :)

    1a. Therefore if you bring up the project proeprties and set a value - it will be local to the project.

    1b. If you want to change the machine wide settings, therefore, you need to go to the property manager, select the property sheet (Microsoft.Cpp.Win32.User.Props), right-click and bring up it's properties. Now it is machine-wide changes....Well, to be precise, it is changes to that file - and therefore affects any project that imports that property sheet (all VC projects by default).

    1c. If you don't want machine-wide settings - because you are working in a source code control env. with other devs on other machines for example - then you can delete the import of the property sheet. You can also create your own property sheets that are in source code control and shared across projects.

    Really, we quickly get into the whole "how do you best design a multiple project/multiple developer enlistment scheme and manage properties across projects" discussion - which is where we get off here. However, I'm hoping we can create some articles and blog posts on this topic because the VC++ project system is very powerful in this regard, but poorly understood by most. And with the move to MSBuild, it's only gotten more powerful.

    2. They are being ignored? Can you go into more detail? Have you opened a connect bug? That doesn't sound correct....
    VS Project Team http://blogs.msdn.com/vsproject
    Thursday, June 11, 2009 8:24 PM
  • I strongly agree that something has to be done about this.  For starters, it is a huge pain to edit the property sheets manually.  Whenever a project is added by default it automatically gets this property sheet (called Application), but it is read-only.  So the only way that I can find to edit the value of this property sheet is to temporarily add it to your project, edit the settings, and then save it and remove it from your project.  This is silly.

    Secondly, even when you do edit it this way nothing happens.  I edit

    Documents and Settings\Me\Local Settings\Application Data\Microsoft\VisualStudio\10.0\Microsoft.Cpp.Win32.User.Props and add my custom directory, then it's not reflected anywhere.  I unload / reload solution and project, still not there. 

    There needs to be an easy, user-friendly way to specify global include / library paths.

     

    Edit: I finally figured out how to achieve this, even though it's hackish.  You have to manually edit the following files:

     

    \Program Files\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\PlatformToolsets\v100\Microsoft.Cpp.Win32.v100.props

    \Program Files\MSBuild\Microsoft.Cpp\v4.0\Platforms\x64\PlatformToolsets\v100\Microsoft.Cpp.Win32.v100.props

    \Program Files\MSBuild\Microsoft.Cpp\v4.0\Platforms\Itanium\PlatformToolsets\v100\Microsoft.Cpp.Win32.v100.props

    and modify the <IncludePath> tag near the bottom.  If you want to affect the global build environment, then you can edit:

    \Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.Cpp.props

     

    For example, to add boost and DirectX SDK to the default build environment, I've added this:

     


      <PropertyGroup>
        <DirectxSdkBase>$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DirectX\Microsoft DirectX SDK (March 2009)@InstallPath)\</DirectxSdkBase>
        <DirectxSdkBase Condition="'$(DirectxSdkDir)' == ''">$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DirectX\Microsoft DirectX SDK (March 2009)@InstallPath)\</DirectxSdkBase>

        <BoostSdkBase>D:\Program Files\boost\default\</BoostSdkBase>
        <BoostSdkBase Condition="'$(DirectxSdkDir)' == ''">D:\Program Files\boost\default\</BoostSdkBase>

        <DirectxIncludePath>$(DirectxSdkBase)Include</DirectxIncludePath>
        <DirectxLibPath>$(DirectxSdkBase)Lib\$(PlatformShortName)</DirectxLibPath>

        <BoostIncludePath>$(BoostSdkBase)include</BoostIncludePath>
        <BoostLibPath>$(BoostSdkBase)lib</BoostLibPath>

        <IncludePath>$(BoostIncludePath);$(DirectxIncludePath);$(IncludePath)</IncludePath>
        <LibraryPath>$(BoostLibPath);$(DirectxLibPath);$(LibraryPath)</LibraryPath>
      </PropertyGroup>

     

    This has the added benefit of demonstrating how to define custom global environment variables, as the above will add the following environment variable macros to be used anywhere one desires: $(DirectxSdkBase), $(BoostSdkBase), $(DirectxIncludePath), $(DirectxLibPath), $(BoostIncludePath), $(BoostLibPath).

     

    Either way, this should be made easier and more user friendly.  Someone who makes numerous projects and solutions all which use common libraries (for example boost), is not going to want to have to manually add all this stuff to the build environment every single time.

    Saturday, July 04, 2009 5:02 PM
  • dvs0826

    Sorry that there has been confusion over how to handle the directory settings - but the approach you took isn't what I would recommend as it requires editing files shipped as part of VS (and thus would be wiped out when a service pack is applied). To help on the subject, I've just posted up a blog entry on VC Directories and what happened in VS 2010. Please take a look and let me know if you have any questions: http://blogs.msdn.com/vsproject/archive/2009/07/07/vc-directories.aspx

    Property sheets are typically not read-only - there are only three cases where a read-only property sheet should occur

    1. A system property sheet (See http://blogs.msdn.com/vsproject/archive/2009/06/23/inherited-properties-and-property-sheets.aspx)
    2. A non-system property sheet that you don't have write-access to (this wouldn't make it read-only in the IDE, but you couldn't save it) - such as things in Program Files if you are running as non-elevated.
    3. The property itself is marked as read-only - typically done when a property is meant to show the calculated value but is itself not meant to be edited.

    If your property sheet experience doesn't fall into one of these, please let us know what is happening. As an extra aside - the property manager view does have a discoverability problem in that changes to property sheets are not saved automatically or as part of "Save All" - instead you right-click on the property sheet and select Save. This has been the UI approach since they were introduced and unfortunately we weren't able to address this in VS 2010 with all the other work that was going on - a big regret for me.

    As to the issue of editing the user property sheet and nothing happening, could you post up the property sheet? I'd like to take a look at it to see what might be happening.

    Some additional suggestions: A quick and easy way to define the DirectxSdkBase, etc. would be to use User Macros - one of the rules available in property sheets - to define your own macro values. This is a great way to define per-machine settings such as install locations.

    Alternatively you could do exactly what you did and define a property sheet - which can then be checked into SCC - that pulls the base locations from the registry. Unfortunately that syntax isn't something we expose from the IDE, so you need to write it manually as you did above - but the IDE will read the property sheet and handle it correctly (or at least it should :) ).

    Finally, if you have several such properties and several developers, it might be worth authoring your own XML file that defines these properties (a custom build rule effectively) so that they display in the property page view just like the CL, LIB, LINK, etc. properties. Again, check the blogs.msdn.com/vsproject for posts we've done on how to do that.


    VS Project Team http://blogs.msdn.com/vsproject
    Tuesday, July 07, 2009 4:54 PM
  • Thanks, I'll definitely take a look at the blog.  One point I want to make is that regarding the issue you mention about discoverability, I had actually entered a similar issue as a VS2k10 bug report recently just the other day (https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=472572). 

    However, the issue I've posted is not related to auto-saving or the save-all button, but with the save disk icon in the property manager.  It works sometimes, sometimes it doesn't.  I'll admit I have never even tried right clicking and choosing Save from the context menu, but I will try this and see if it resolves the problem. 

    Honestly though with the way that the focus is shifting more and more toward property sheets for configuration (even moreso with removal of the global project directories option, although I'm still hoping that UI will come back before release) I think that the VS property manager should be a high priority.  You pretty much -need- property sheets for all but the most trivial of solution configurations, and it feels like the black sheep of the family that gets no attention.  With Visual Studio 2008 SP1 there were tons of bugs in the property manager, I would encounter them regularly almost to the point that it made me not even want to use it.  And as mentioned above, I've confirmed at least one of the most annoying of these bugs still exists (the save disk icon).  I've found at least 3 other bugs with the property manager (See, for example, https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=472988, and a few others that I will submit within the next few days).

    Regarding your suggestion about UserMacros and property sheets, that's essentially the solution I've ended up using but what is lacking is a global way for me to automatically have certain property sheets added to new projects.   I agree it's slightly less painful to manually add a property sheet to every project you ever create than it is to define a multitude of include / library paths for every project you ever create, but it's still not ideal. 

    If you -really- want to get away from allowing actual system-wide settings (a la global VC++ Directories in 2008) while still giving the user the flexibility to achieve similar results, I would suggest that there be some way to specify solution-wide Property Sheets that will be inherited by every project in a solution (including projects that have not yet been added).  Perhaps in Project -> Properties -> Common Properties (What is that Framework & References option even for?  Does anyone really use that in unmanaged C++?).  It's not that difficult to highlight every project in the solution and click Add Existing Property Sheet, but this doesn't exactly make it clear that each project has a reference to the -same- property sheet.  When I was first learning how to use property sheets it was confusing to no end that editing a property sheet in foo | Release | Win32 caused the changes to be reflected in bar | Debug | x64.



    One last question: When I go to Add New Property Sheet, it pops up with the dialog that contains a list of installed templates.  Can you point me to something that describes how to make my own property sheet template?  What I'd also like is a way to take an existing property sheet and add it to that list, so that when I click it from the Add New Property Sheet window it actually puts a *copy* of the property sheet into my project.  I have a property sheet that I use frequently, but some of the values are solution-dependent.  So it would be nice to have everything filled out so that after adding it to the project I can open it up and change 1 or 2 values to be the ones that are needed for the particular solution.
    Tuesday, July 07, 2009 5:21 PM
  • dvs0826

     Please take a look and let me know if you have any questions: http://blogs.msdn.com/vsproject/archive/2009/07/07/vc-directories.aspx VS Project Team http://blogs.msdn.com/vsproject


    Ok so I have read your blog post and I have what appears to be a strange problem.  You mention this in your blog post:

    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


    This does not happen for me, and perhaps this is the source of my confusion all along.  Whenever I create new C++ projects, I open the property manager and the entire tree displayed looks like the following:


    --test
    ----Debug | Win32
    ------Application
    ------Unicode Support
    ------Core Windows Libraries
    ----Release | Win32
    ------Whole Program Optimization
    ------Application
    ------Unicode Support
    ------Core Windows Libraries


    Maybe I should try a repair of my installation?
    Tuesday, July 07, 2009 11:46 PM
  • I think I have some potentially useful information regarding this problem.

    I opened up my .vcxproj file in notepad and saw that it did indeed have the following lines:

      <ImportGroup Label="PropertySheets">
        <Import Project="$(LocalAppData)\Microsoft\VisualStudio\10.0\Microsoft.Cpp.$(Platform).User.Props" Condition="exists('$(LocalAppData)\Microsoft\VisualStudio\10.0\Microsoft.Cpp.$(Platform).User.Props')" />
      </ImportGroup>


    So as a quick test I deleted the "exists" condition and loaded the project and got an error message saying that D:\Microsoft\VisualStudio\10.0\Microsoft.Cpp.Win32.User.Props could not be found.

    Is this a bug in Visual Studio?  $(LocalAppData) should resolve to D:\Documents and Settings\MyUserName\Local Settings\Application Data\Microsoft\VisualStudio\10.0


    Edit: I solved this and I do believe it's a bug in Visual Studio.  %LocalAppData% is a system environment variable defined per-user but does not exist by default prior to Windows Vista.   Either the Visual Studio installer should check whether it's being installed on Windows XP and if so add the environment variable, or the configuration files should be changed to use $(UserProfile)\Local Settings\Application Data instead of $(LocalAppData).

    By manually creating this environment variable on my system and restarting visual studio 2010, the property sheet is now added as it should be. 

    I'm going to go ahead and submit this as a bug report now that I finally know what's wrong.
    Thursday, July 09, 2009 1:19 AM
  • thanks for this discovering. because of this bug and the lack of info in this blog(http://blogs.msdn.com/vsproject/archive/2009/07/07/vc-directories.aspx). I was not able to get the VC dirs right at all and only had to give up trying Visual C++ 10 IDE.

    I was so disappointed how MS could ship it as buggy as this way. 
    Thursday, July 09, 2009 3:41 AM
  • Don't be discouraged.  It's only Beta 1, there's still going to be Beta 2, and then probably even Release Candidate.  So every time you're frustrated by a bug, submit a bug report about it so that Beta 2 is much better!  I think I've submitted about 30 bug reports already.

    Anyway, hopefully with this info you can get your directories configured right.  After you create the environment variable, just double click the property sheet, add all your directories in the property sheet's settings, and save.  You should be good to go then :)
    Thursday, July 09, 2009 4:03 AM
  • Thanks, Manually added the property sheet is OK now.
    I did report the bug through connect and was closed as "unable to reproduce". I am happy I can fix this problem and start to use it now as I've been so eager to test all the C++ 0x stuff.
    Thursday, July 09, 2009 10:07 AM
  • dvs0826 - That is some serious detectoring work you did there - and yep, you found the bug where the variable we need isn't on XP. I can say that has been fixed now.

    tomG - I'm very sorry that you didn't find the blog helpful. I know that the beta1 has several bugs in the property sheet UI, so I imagine it can be frustrating trying to compare what I said with what is in front of you. If you have any specific questions, please post them up and I'll try to get back to you.

    As to the bug closed as "unable to reproduce", is that something that you can still reproduce? I'm not sure whether it was closed that way because it was tried against the lastest internal drop or not...

    VS Project Team http://blogs.msdn.com/vsproject
    Thursday, July 09, 2009 8:30 PM
  • dvs0826 - That is some serious detectoring work you did there - and yep, you found the bug where the variable we need isn't on XP. I can say that has been fixed now.
    I have to admit I was going insane trying to figure out what was going on.  But it definitely feels good to solve something like that. 

    Was this a known issue before I found it? 

    Oh and the other day I mentioned that I was going to be sending some bug reports your way regarding property sheets.  I hope you're prepared for an onslaught, I think I've submitted over 20 already :)
    Thursday, July 09, 2009 9:17 PM
  • Thanks for the quick response. I probably should have found here earlier for answers weeks ago.

    The specific bug I reported was actually a mess resulting from the lack of  Microsoft.Cpp.Win32.User.Props: the project cannot compile due to boost header files missing, while the IDE could navigate to the header files by right clicking on the #including lines. I was speculating that the IDE and comiper use different way to locate the source file dependencies.  I uploaded quite a few pictures illustrating the steps and together with the project. However it did not seem to help.  

    Now I realize that you cannot reproduce it most probably because you always have microsoft.Cpp.Win32.User.Props there. 

    As one can actually remove the dependency to microsoft.Cpp.Win32.User.Props, the messy I encountered would actually happen to some one again. You probably need to fully test this scenario.

    Friday, July 10, 2009 2:29 AM
  • i cant find the vc++ directories in the tools > options in beta2 either.. why was it even removed? surely that yould not have been intentional..
    but if its a bug, why didnt you fix it? surely there must be alot harder bugs out there...


    "yeah we gotta fix those bugs, add some features, and that ability to globaly set VC++ directories gotta go, the users are far better of going to a 7+ deep folder structure thats hidden by default and manually editing a bunch of text files"
    seriously, what where you thinking? :)

    [yeah going through the property manager is slightly easier, but its still far far to hidden for such a basic feature :) ]
    Tuesday, January 05, 2010 7:34 PM
  • Still busted for XP even with Release Candidate RC1Rel
    Thursday, April 08, 2010 7:10 PM
  • Hi, moving VC++ Directories out of Tools.options and to user property file is a by design change in VS2010. You can take a look of this blog: http://blogs.msdn.com/vcblog/archive/2010/03/02/visual-studio-2010-c-project-upgrade-guide.aspx, which has mentioned about the change and the new ways to set up the VC++ directories.

    VC++ Directories change

    VC++ Directories are no longer supported in VS2010 through Tools->Options page. Instead, VS2010 introduces the user settings file (Microsoft.cpp.<Platform>.users.props) to control global settings including Global search path. These files are located at $(USERPROFILE)\appdata\local\microsoft\msbuild\v4.0 directory. Upon migration to VS2010, the custom settings of VC++ Directories from VS2005 or VS2008 are migrated to these user files. These global settings files are imported into all the converted and newly created projects.

     

    Here are the steps to change the settings file through UI:

    ·         Open up property manager by clicking on View.Property Manager.

    ·         Expand the project node and then the Configuration|Platform nodes, you will see "Microsoft.cpp.<Platform>.users" file for each Configuration|Platform. These are the files for the global settings, similar to the old tools/Options/VC++ Directories.

    ·         Multi-Select "Microsoft.cpp.<Platform>.users", right click and bring up the property page window

    ·         In the property page window, click on "VC++ Directories" (for example) in the left pane, add new paths for the directories such as "Include Directories". separated by semicolons

    ·         Make sure to save the settings before shutting down Visual Studio.

    ·         Re-launch Visual Studio and the new settings will be in effect.

    -Note: If you would like to only change the settings for one project, you can right click on the project and bring up the property page. Change the settings for “VC++ Directories”, these settings will be persisted to the project file.

    One of the advantages with this change is that VC++ directories are no longer per machine but per user.  In addition, if you move the settings file to your enlistment directory and change the import in the project file as needed, you also have the option of check in the user.props files and save your project settings in the source control.

    Li Shao, MSFT

     


    Li Shao
    Friday, April 09, 2010 3:03 AM
  • I understand it's no longer supported through the Tools -> Options. But it still doesn't work at the user level through the property manager either. I even set up the environment variable LocalAppData. I then did a scan on my hard drive for all *.props files. No 'Microsoft.Cpp.$(Platform).User.Props' to be found anywhere.

    Friday, April 09, 2010 2:14 PM
  • I should have mentioned that this file is hidden file, you need to dir /AH to see it.

    Li Shao, MSFT


    Li Shao
    Saturday, April 10, 2010 6:08 AM
  • Sorry I was referring to vccomponts.dat  as a hidden file, which is the file that is used to store custom C++ directories in the previous versions of Visual Studio.

    'Microsoft.Cpp.$(Platform).User.Props'  is not on the disk for  fresh VS2010 installation. It will be generated for once you have converted projects or have created new projects. Once generated, you can find them under $(USERPROFILE)\appdata\local\microsoft\msbuild\v4.0 directory.

    Li Shao, MSFT 


    Li Shao
    Monday, April 12, 2010 5:54 AM
  • I believe that there is also a need for a per-solution VC++ directories, something that seems arkward to me so far.

    My scenario is a solution of quite many console projects each testing a math distribution.  whereas for most projects, I am fine with a per user setting to the latest Boost release, for these I might want to test each or all projects against the latest unreleased stuff in Boost trunk.

    I'm not clear how best to do this without adding a property page to each project, so the setting is solution wide (and can be changed for all projects together, for example to test against a particular release.

    Am I missing something?


    Paul Bristow
    Wednesday, August 04, 2010 11:57 AM