We do currently support the notion of different project configurations for PTVS projects, but they're pretty useless in practice for anything other than custom build actions, because all our project properties are not config-specific. Even if you do manually
edit the project file to make them config-specific, we do not actually respect this in practice.
There are several interesting scenarios for varying properties with configs. One would be to allow quickly switching interpreters in sync for several projects in the solution (by specifying different interpreters for different project configs, and bind them
all to the matching solution configs). Another is to change the search path depending on target interpreter, so as to use a proper version (2.7/3.3, x86/x64) of a binary module - this is particularly useful when said modules are built from a C++ project in
the same solution in mixed code scenarios.
Ideally, we should make all project properties config-dependent. The most interesting ones are:
- interpreter to use
- search path
- startup file
In addition, we should also consider supporting config|platform combinations for all the available platforms (Win32/x64/ARM) in addition to AnyCPU. While they don't really make much sense for Python itself, they do make sense once native modules are involved
- so, again, the search path between x86 and x64 could differ, for example.
This would also provide a solution to