views:

426

answers:

1

Visual Studio 2010 no longer has the "VC++ Directories" page under Tools / Options. It's been superseded by the Property Manager, and I'm unsure how best to use this.

For example, I've got a solution containing multiple projects, all of which require a header file from the Microsoft SMS SDK. This SDK is installed in the same place on all of our developer workstations; for Visual Studio 2008 we just edited the VC++ Directories appropriately.

It feels like I should be adding a new "SMS 2003 SDK" property sheet with the correct details, and then adding this to every project in my solution.

Some questions about this approach:

  1. Where should this property sheet live? If I open the solution file on another PC, where does it look for the property sheet? Or in other words: when setting up the gold image for our dev PCs, where should this file be placed?
  2. Do I really have to edit every project in the solution? This is time-consuming and feels fragile.
  3. At what point do I decide to use a custom property page over editing the Microsoft.Cpp.Win32.user property page? The majority of my projects need the SMS 2003 SDK. Only some need WTL.

Any other tips for working effectively with VS2010 property pages?

+1  A: 

I usually keep Property Sheets in root directory of solution (i.e. trunk/ directory in SVN repository):

/projectA/projectA.vsprops    
/projectA/library1
/projectA/library2
/projectA/app1

Sometimes I have number of Property Sheets divided by subject, for instance boost-svn.vsprops, xercexs-2.8.vsprops, etc. and combine them together according to what I need for a project.

You do not need to edit every project, but you do need to add particular Property Sheet to every project in solution.

In Visual Studio 2010 Tools -> Options have been replaced with Microsoft.Cpp.Win32.user and this is the file where machine-wide settings should go. So, in your case I would put the SMS SDK settings to Microsoft.Cpp.Win32.user file on ever developer's machine. It would also give developers flexibility to install the SDK in different location (i.e. drive) on their machine and also free your solution/projects from maintaining environment-specific settings.

mloskot