"Before Building" custom step – "PATH" missing?

Sysprogs forums Forums VisualGDB "Before Building" custom step – "PATH" missing?

This topic contains 6 replies, has 2 voices, and was last updated by  support 1 week, 4 days ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
  • #26101


    I have a project that uses a batch file to call a python script. For reasons that I don’t understand, the batch file that I have VisualGDB executing does not have access to the system environments Path variable. When I enter ECHO %PATH%, it returns an empty string. This is strange because when I do a “set” command, all of the other system environment variables show up. What causes this and what workaround can I use to get access to the path directories?



    Sorry, we are not aware of this issue. Please try checking if other variables get overridden as well (e.g. by running ‘set’ instead).

    If this doesn’t help, please try creating the most basic repro project and share it with us so that we could try replicating this.  That said, please also ensure the VS instance you are using doesn’t inherit some custom environment and that your environment block doesn’t exceed Windows limits.



    None of the other variables get overridden, just ‘path’ which is now empty. I noticed that if I open the project via Visual Studio (Start–>Visual Studio 2017, and then doing File->Open->Solution), I now have access to ‘path’. If I have *never* opened it that way, but only just opened it by double-clicking the solution, then the path is missing.

    Way to reproduce (for me):

    1. Take a working project
    2. Copy and paste the project (so it creates a new folder. can be in the same directory.)
    3. Double-click the solution
    4. Create a pre-build batch file that just has “set” or “python -h” in it.
    5. Build the project
    6. The project will not show path as a system env variable. It will also complain about not being able to find python (due to missing path).
    7. Open Visual Studio Start->Visual Studio 2017
    8. Open solution
    9. Build project again. Now you will see that it does have the path variable and “python -h” shows the appropriate python help info.

    Can you reproduce it with this? You can try one of your own projects, but be sure to do a copy/paste.


    • This reply was modified 1 week, 6 days ago by  Seidleroni.


    Sorry, this might be something set on the VS level. Please try running notepad.exe instead of the batch file (so that the build waits until you close Notepad).

    Then use the  Process Explorer to check the environment block of the Visual Studio itself (devenv.exe), launched Notepad instance and the MSBuild executables (msbuild.exe) if you are using MSBuild.

    Let us know at which stage is the PATH reset and we might be able to suggest a workaround.



    So by doing this, here is the hierarchy and breakdown:

    • devenv.exe (Path is present)
      • MSBuild.exe (Path is *not present*)
        • vgagent.exe (Path is *not present*)
          • cmd.exe (Path is *not present*)
            • notepad.exe (Path is *not present*)

    What are the next steps to work around this?



    After spending an inordinate amount of time on this, I fixed the issue by deleting my PreBuild action and then recreating it. Attached is an image comparing the vgdbsettings file change that made it happen. What could cause this? Is this just a stupid error on my part?

    You must be logged in to view attached files.


    Sorry, the settings in both cases look equivalent. To be fully sure, please consider reverting them back and forth 2-3 times and checking if the problem reoccurs consistently.

    As a long-term workaround, please consider setting the GNUToolchainExtraPath MSBuild variable in the .vxcproj file. It is used internally by VisualGDB to propagate path directories exported by the selected toolchain, so you can edit it to inject the Python path into the environment as well.

    Also, as the variable is lost between Visual Studio and MSBuild, it could be worthwhile verifying if the problem can be reproduced with the regular Exec task on a regular non-VisualGDB project and checking with the Visual Studio support whether it’s a bug that could be fixed on the VS side or if there is a setting controlling this behavior.

Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.