Uploaded image for project: 'Bamboo Data Center'
  1. Bamboo Data Center
  2. BAM-20611

devenvrunner.bat loses working directory setting when called and run.

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Low Engagement
    • Icon: Low Low
    • None
    • 6.9.2
    • Tasks

      Summary

      devenvrunner.bat loses working directory setting when called and run.

      Environment

      • Bamboo 6.9.2
      • Plan building with Visual Studio.

      Steps to Reproduce

      1. Create a plan with a Visual Studio task.
      2. Make the plan run, using the variable BAM_WORK_DIR at some point.

      Expected Results

      Build works as expected

      Actual Results

      Variable loses its value.

      Notes

      Apparently the dot-net plugin is overwritting the file every time the build runs, therefore it's not possible to permanently edit this file.

      Workaround

      Modify the content of the file <bamboo-agent-home>\DotNetSupport\devenvrunner.bat when the build runs, from 

      cd "%BAM_WORK_DIR%"

if exist "%BAM_VS_HOME%\VC\Auxiliary\Build\vcvarsall.bat" (
SET VCVARSALL="%BAM_VS_HOME%\VC\Auxiliary\Build\vcvarsall.bat"
) else (
SET VCVARSALL="%BAM_VS_HOME%\VC\vcvarsall.bat"
)
@echo on
call %VCVARSALL% %BAM_VS_ARCH%
call "%BAM_VS_HOME%\Common7\IDE\devenv.com" %BAM_ARGS%
exit ERRORLEVEL

      to 

      if exist "%BAM_VS_HOME%\VC\Auxiliary\Build\vcvarsall.bat" (
SET VCVARSALL="%BAM_VS_HOME%\VC\Auxiliary\Build\vcvarsall.bat"
) else (
SET VCVARSALL="%BAM_VS_HOME%\VC\vcvarsall.bat"
)
@echo on
call %VCVARSALL% %BAM_VS_ARCH%
cd "%BAM_WORK_DIR%"
call "%BAM_VS_HOME%\Common7\IDE\devenv.com" %BAM_ARGS%
exit ERRORLEVEL

            [BAM-20611] devenvrunner.bat loses working directory setting when called and run.

            Ishwinder Kaur made changes -
            Resolution New: Low Engagement [ 10300 ]
            Status Original: Long Term Backlog [ 12073 ] New: Closed [ 6 ]

            Ishwinder Kaur added a comment -
            Atlassian Update - 9 April 2025

            Hi,

            At Atlassian, our goal is to ensure we’re providing the best experience for our customers. With our new Data Center strategy, Atlassian's focus is on security, compliance, and performance and is a key driver in prioritizing bugs. Closing the bugs that do not fall into those categories will allow us to focus on the ones in the most current versions of our products.

            This bug is being closed due to a lack of engagement in the last four years, including no new watchers, votes, or comments; this inactivity suggests a low impact.

            Please note the comments on this thread are not being monitored.

            You can read more about our bug fix policy here and how we prioritize bugs.

            To learn more about our recent investments in Bamboo Data Center, please check our public roadmap.

            Kind regards,
            Bamboo Data Center

            Ishwinder Kaur added a comment - Atlassian Update - 9 April 2025 Hi, At Atlassian, our goal is to ensure we’re providing the best experience for our customers. With our new Data Center strategy, Atlassian's focus is on security, compliance, and performance and is a key driver in prioritizing bugs. Closing the bugs that do not fall into those categories will allow us to focus on the ones in the most current versions of our products. This bug is being closed due to a lack of engagement in the last four years , including no new watchers, votes, or comments; this inactivity suggests a low impact. Please note the comments on this thread are not being monitored. You can read more about our bug fix policy here and how we prioritize bugs. To learn more about our recent investments in Bamboo Data Center, please check our public roadmap . Kind regards, Bamboo Data Center
            Ishwinder Kaur made changes -
            Labels New: cleanup-seos-fy25
            Jan Majkutewicz (Inactive) made changes -
            Status Original: Short Term Backlog [ 12074 ] New: Long Term Backlog [ 12073 ]

            Herman Yih added a comment -

            Is devenvrunner.bat only available through bamboo-dotnet-plugin.?

            Herman Yih added a comment - Is devenvrunner.bat only available through bamboo-dotnet-plugin .?
            Bugfix Automation Bot made changes -
            Support reference count New: 1
            Pawel Skierczynski made changes -
            Remote Link New: This issue links to "BDEV-15584 (Hello Jira)" [ 449515 ]
            Pawel Skierczynski made changes -
            Status Original: Needs Triage [ 10030 ] New: Short Term Backlog [ 12074 ]

            Matthew Pass added a comment -

            Please ignore my previous comment about increasing the priority and symptom severity. I've found a more permanent workaround.

            The issue arises because deep in the chain of batch files called by vcvarsall.bat, the file ...\Common7\Tools\vsdevcmd\core\vsdevcmd_end.bat gets called which, in the particular version of Visual Studio 2017 that we had installed, changes the current directory to %USERPROFILE%\Source if this directory is found.

            By deleting %USERPROFILE%\Source and setting Visual Studio's Projects location to somewhere else (so the Source directory is never created by VS), everything now works with the built-in devenvrunner.bat.

            Looking at a later version of Visual Studio 2017, it seems that this changing of directory is now guarded against by default (a -startdir parameter has been introduced), which probably explains why this issue hasn't been reported elsewhere.

            My recommendation would now be to keep the priority as low and the symptom severity as minor, and to be fair it's probably not worth changing anything for this issue based on the fact that it's an edge case that is resolved by installing a later version of Visual Studio 2017.

             

            Matthew Pass added a comment - Please ignore my previous comment about increasing the priority and symptom severity. I've found a more permanent workaround. The issue arises because deep in the chain of batch files called by vcvarsall.bat, the file ...\Common7\Tools\vsdevcmd\core\vsdevcmd_end.bat gets called which, in the particular version of Visual Studio 2017 that we had installed, changes the current directory to %USERPROFILE%\Source if this directory is found. By deleting %USERPROFILE%\Source and setting Visual Studio's Projects location to somewhere else (so the Source directory is never created by VS), everything now works with the built-in devenvrunner.bat. Looking at a later version of Visual Studio 2017, it seems that this changing of directory is now guarded against by default (a -startdir parameter has been introduced), which probably explains why this issue hasn't been reported elsewhere. My recommendation would now be to keep the priority as low and the symptom severity as minor, and to be fair it's probably not worth changing anything for this issue based on the fact that it's an edge case that is resolved by installing a later version of Visual Studio 2017.  

            Matthew Pass added a comment -

            Is it possible to increase the priority and symptom severity of this issue? While there is technically a workaround by editing the batch file, this continually gets overwritten and leads to numerous failed builds which is very frustrating.

            Matthew Pass added a comment - Is it possible to increase the priority and symptom severity of this issue? While there is technically a workaround by editing the batch file, this continually gets overwritten and leads to numerous failed builds which is very frustrating.

              Unassigned Unassigned
              pdemitrio Patricio
              Affected customers:
              1 This affects my team
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: