TestStand Deployment with Relative Source Paths

[shew82]

Is there any way to set up the TestStand Deployment Utility to use relative paths instead of absolute for source files?

For example, on my system, the TestStand code may be checked out to C:\Users\shew82\Documents\My TestStand Projects, whereas my coworker may use C:\TestStand Projects. In this case, if I create the TSD file, the paths will all be things like "<UserProfile>Documents\My TestStand Project\Project A\Sequence.seq" etc (I believe this level of relative-ness is supported)... The problem is that when my coworkers open up the TSD, he/she needs all of the files to be C:\TestStand Projects\Project A\.... etc.

If instead the files were just ".\Sequence.seq" etc  (or even ..\Folder\Sequence.seq) etc then things would pesumably just work... I can't seem to find a setting for this... Am I missing something?

Thanks,

Shaun

[D-Cubed]

Hi Shaun,

Are you using a source control program to make changes to your TestStand Deployment?  If you are, this forum post may be useful for deciding on a good configuration.  If you are using a Workspace, you can set a relative path as the Path Name from the General tab of the Workspace Object Properties dialog.

Please let me know if you are looking for different information, and I can try to point you to the correct resource.

Warm Regards,

[flaborde]

Shaun,

You are correct in saying that the Deployment Utility will convert paths to pseudo paths based on the location for special directories like the TestStand public directory, user profile and desktop. Unfortunately there is no option to disable this behavior. 

We are aware of this limitation and I have created a request to improve on this in a future version of TestStand. If you are using Windows Vista or Windows 7 (looks like it from the paths you posted) you could trick the Deployment Utility into thinking that it is deploying from a different directory by using the following command: 

mklink \d "C:\Deployments\TestStand Projects" "C:\Users\shew82\Documents\My TestStand Projects"

And then creating the TSD on the C:\Deployments directory so that you have a relative path of .\TestStandProjects. This is not an ideal solution because source controls is more complicated since you have two different branches but unfortunately current versions of the Deployment Utility do not support your use case.

I hope this helps,

Francisco

[shew82]

Using a workspace file helped somewhat but there are still issues:

1. When I open up the TSD file, everything is just great

2. When my coworker opens up the TSD file things always need changing:

     a) Deployment Utility complains that it cannot find the workspace file thats in the same folder as the TSD file.Browsing to this appears to work but is a pain

     b) On my machine, the image and installer are both created in subfolders relative to the TSD... on my coworkers machine there's completely different (as he has his code checked out in a different location)

This means that there is no way for a coworker to rebuild an installer etc without having to edit a bunch of settings first, which makes much more opportunities for error.

Is there something else I'm missing?

[Teds]

Hello

I have always had the same problem with the TSD not finding the Workspace file (*.TSW).  These do not seem to be relative pathed, because as you had said, even if it is the same directory it sometimes can't find it.

For me it does find the 'correct' TSW file if the following conditions are met:

1.)  The 'existing' workspace file that was pointed to by the TSD file does NOT exist on disk at that location.  For some reason it seems the TSD file uses an absoulte path to search for it first.  I would expect it not to do this.  Odd.

For example:

c:\BUILD\Generic Test.TSD  points to the TSW file below in the same path.

c:\BUILD\Generic Test.TSW

Now if I open Generic Test.TSD anywhere else, it will still try to locate the Generic Test.TSW file in the C:\BUILD location.  So normally I have to DELETE the TSW files of the same name from any other locations on the PC.  Kinda of a pain.

Plus pointing the TSD to the correct workspace file seems to mess up some of the setting in the deployment utility.   But again, I guess that is the price we have to pay to use TestStand.

My 2 cents.

Thanks,

PH

[flaborde]

What version of TestStand are you using? We have fixed several issues with loading file paths in different machines in TestStand 2012. 

The issue you are describing usually happens when you move the TSD and the workspace to different locations instead of moving them as a block so that both the absolute paths and the relative paths change. For example, if you have the following structure:

<TestStand Public>

• TestSystem.tsd
• TestSystem.tsw
• TestSystem.seq
• Code Modules
•  MyVI.vi

And move the files to the following structure:

<TestStand Public>

• My Test System
• TestSystem.tsd
• My Code
• TestSystem.tsw
• TestSystem.seq
• Code Modules
•  MyVI.vi

Then we will not be able to figure out what the new paths are because both the relative path from the TSD to the workspace and the absolute paths to the files changed.

The TSDU will first attempt to create a relative path to the workspace file from the TSD file using the same relative path as we had before, if that fails then we will attempt to find the file in the old absolute path, if that fails then we will show the prompt that asks for the new location of the workspace file because we have no idea where it is located now. 

When you are creating your test system structure or moving TSD files between different computers, please make sure to move all the files as a block to avoid this problem. If you want to change the relative paths from the TSD to the workspace or other top level files you can also make the change in two steps, changing the path of the TSD, then opening the TSD and analyzing and then saving the TSD again and moving everything as a block.

I hope this helps,

Francisco

[shew82]

I'm using TestStand 2012 SP1 so the problem still remains...

Here's are setup:

My Developement Setup

C:\Users\<username>\_Projects\Project1\Software\Project1 Deployment.tsd

C:\Users\<username>\_Projects\Project1\Software\Project1 Workspace.tsw

C:\Users\<username>\_Projects\Project1\Software\Project1 Project.tpj

C:\Users\<username>\_Projects\Project1\Software\Sequence 1.seq

C:\Users\<username>\_Projects\Project1\Software\Sequence 2.seq

C:\Users\<username>\_Projects\Project1\Software\LIB\Labview code module 1.lvlibp

TSD specifies that Image and Installer are saved in:

C:\Users\<username>\_Projects\Project1\Deployment\Image

C:\Users\<username>\_Projects\Project1\Deployment\Installer

Now, my co-worker uses C:\Work as his root (although code checked out of the same respository) and as such has:

c:\Work\Project1\Software\Project1 Deployment.tsd

c:\Work\Project1\Software\Project1 Workspace.tsw

c:\Work\Project1\Software\Project1 Project.tpj

c:\Work\Project1\Software\Sequence 1.seq

c:\Work\Project1\Software\Sequence 2.seq

c:\Work\Project1\Software\LIB\Labview code module 1.lvlibp

When my co-worker opens the TSD he experiences the following:

1. TestStand Deployment Utiltiy cannot find workspace C:\Users\<HIS username>\_Projects\Project1\Software\Project1 Workspace.tsw

2. After re-specifying the workspace file, re-analyzing files, etc, things seem mostly consistent exect:

3. His build ends up at C:\Users\<HIS username>\_Projects\Project1\Deployment\Image and Installer (somewhere where he was NOT expecting)

#1 and 2 drive me crazy as this just seems a prime opportunity for mistakes to happen (as the installer definition is being changed)

#3 could be resolved by using a common path, but this is 2013... we shouldnt have to be doing that.

There should be a way that installer definitions to have to be edited and recreate just because a different person maintains a product.

[flaborde]

Thanks for the information. Unfortunately the Deployment Utility treats some folders as special directories; the Desktop directory, the TestStand folder, the user profile folder and the TestStand Public directory are considered special directories and all paths are created relative to that directory instead of to the TSD. I have added a note in the bug report about your specific case and how having different source control roots in both the user directory and outside the user directory leads to this problem.

I can't think of many good solutions in the current version of TestStand, one option would be to create a symbolic link from C:\Work to C:\Users\<username>\_Projects in your machine and use the C:\Work directory to create the TSD, but I understand this is not ideal. The other option would be switching your whole source control root to a directory outside the user profile directory. 

I am very sorry that the Deployment Utility does not support your use case. I have updated the bug report with your most recent comments and the internal tracking number (in case you want to check in the next versions to see if it is fixed) is 409089.

- Francisco