Forum Discussion

e_sommer's avatar
e_sommer
New Contributor
10 years ago

Strange Behaviour with environment variables

I set a up a complete new project for a colleague and me. We decided to use the project in shared mode on a shared network drive.

For the Tested Apps we introduce environment variables. So I set up: "%pathToApp%\applicationName.exe"

The environment variable is mapped to the drive "C:" drive on both of our computers. The project is located in "H:".

When I save the project and my colleague open it the entry of the Tested App had changed mysteriously. Infront of "%pathToApp%\applicationName.exe" is now another "\", which TC interprets as "H:\". So the path to the application on his computer is now: "\%pathToApp%\applicationName.exe" or according "H:\C:\pathToApp\applicationName.exe" ... and that is garbage. As long as he doesn't save the file "TestedApps.tcTAs" again the additional "\" doesn't appear there. When I open the project again the error doesn't occure at my computer.



Thanks in advance

Erik

2 Replies

  • TanyaYatskovska's avatar
    TanyaYatskovska
    SmartBear Alumni (Retired)
    Hi Erik,



    I cannot tell you for sure if this behavior is correct or incorrect. Could you please refer this question to our Support team as they need to perform some investigation?


     

  • I was able to reproduce the problem that Erik described but we both found that the problem went away upon reboot.  To repeat the symptoms...



    Two different machines shared a  project residing on some remote directory.  Didn't matter if access to the project was in "shared" mode or not.  When the TestedApps panel was modified for any reason (and saved) on the one machine, the other machine would be updated and a backslash was prepended to the value in the Application textbox.  This seemed to happen for any Application string that did not start with "C:".  The error always seemed to happen one way but not the other.  That is, it was only machine A that would ever see a backslash when a change on machine B caused an update but never would machine B see such a problem when a change on machine A caused an update.  I couldn't see the problem with 10.30 but could with 10.40.



    As mentioned, a reboot resolved the issue.