Great question - And I apologize up front for the fact that our blog (
http://blogs.msdn.com/vsproject) is still sitting empty. I've been wanting to get a lot of information up there, but I think it should start happening after the holidays.
In VS2008, these directories (IncludeDirectories, LibraryDirectories, etc) were all defined in the Tools->Options window and set on a machine-wide basis. The problem with this, however, is that forced all projects to have the same values. So in VS2010, we've changed these to be project properties. Specifically, you can use property sheets to define the values and then include these property sheets to any projects that need them. Thus, rather than having a single definition, you can have a property sheet per-SDK if you wish. Additionally, if your SDK is installed in your source control enlistment instead of per-machine, you can actually check in the property sheets so the paths remain shared. Of course, you can also set these per-project as well as via property sheets.
So, now when you bring up your property pages, you'll see a new category of "VC++ Directories".
As for the API access - let me explain about the split-personality that VCPlatform has undergone. Because basically everything about the project system is now driven by the MSBuild project information, there really is little that the VCPlatform interface can do without any project loaded. So, if you obtain the instance of VCPlatform from VCProjectEngine, you'll find that it does very little. However, if you obtain it from VCConfiguration, you'll find that it starts to respond to these sorts of methods (so you can programatically get/set the directories for a given project). Also, we are going to be introducing some new COM interfaces that are much more generic. Because of the platform extensibility offered in VS2010, there is no way to expose all the new possible properties via the standard, strongly typed VC interfaces. This new COM interface allows you raw access to get or set any MSBuild property in a property sheet or project.
What about SDK providers? The model we are recommending is that SDKs would install a property sheet that defines the correct values for the directories for their SDK. Any project that wants to use that SDK would then simply import the property sheet. If the SDK wants to become even more integrated, then it would be a matter of installing additional files into the platform extensibility model. This model would let them provide a machine-wide (or more configurable) installation similar to the VS2008 model. To explain that is going to take more space and I think this answer is already over it's limit :) Please let me know if you are interested in that.
In the CTP, not all the bits for this are in place, so not everything above is available yet. But you'll see this in the beta.
Getting system include paths from the new project system
