This project has moved and is read-only. For the latest updates, please go here.


Support project configurations in a meaningful way


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
Closed May 4, 2015 at 7:37 PM by Zooba


speedninja wrote Jul 28, 2013 at 10:56 PM

If we link our C++ modules with 3rd party DLLs, we might also need to extend the PATH variable in addition to the search path for PYTHONPATH.

Generally speaking, specifying an environment on start would be nice (As is it is VC++). This way, you could have different environments in Debug/Release as well.

pminaev wrote Jul 29, 2013 at 12:13 AM

Looks like we already have a feature request to add support for set environment for debugging:

This one will track the ability to do so per-config. Though I hope that in the end we'll do both at the same time.