Relative file paths, and the .NET adapter.

[Mac671]

I have a test sequence that uses the .NET adapters quite a lot.

Since this test is a test on files, some of the .NET method calls accept file paths as parameters.

The .NET dll, the files I'm testing and the sequence file all reside in the same directory on the hard drive.

The file path for the dll method calls is passed via test stand by using the path data type,

and the path variable in TS contains only the file name, this way I wanted to ensure that no matter where the test is downloaded 

as long as the test sequence and the tested files reside in the same directory the test should run. 

When I go to test stand and open the sequence file via the File->Open and navigate to the seq file, and run the sequence everything works ok.

But when I opened a new test stand instance, and clicked on the recent files, and tried to load the sequence it blew up on me:

The instance of the .NET class could not be retrieved.

Could not find file 'D:\Program Files\National Instruments\TestStand 4.1\Name.Extension'.

Source:  mscorlib   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)

   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)

(...) <- more stack trace, but irrelevant to the problem

As you probably figured out by now the directory the seq file is is not the "D:\Program Files\National Instruments\TestStand 4.1" but some other dir.

The directory above is where I've installed TS on my machine. 

1) My question is why is this setting depend on the path I choose to open my seq file in the settings editor? 

2) Am I doing something wrong making an assumption that the seq file location should be taken as the relative path? Or is this a TS Bug?

3) Any suggestions what I should do in my test sequence to make it work regardles of the way how you choose to open it in TS.

Thank You for any help,

Maciej 

Message Edited by Mac671 on 08-27-2009 03:42 AM

[dug9000 · Accepted solution]

Maciej,

Is the path you are referring to one that you are just passing in as a parameter to your own code? What are you doing with the path?

For most Windows SDK functions and other library functions, if you use a relative path, Windows expects to find the file relative to the current working directory. The current working directory is set by the open file dialog when you browse to a specific directory and by many other things and is global to the entire process. Therefore you can't and shouldn't rely on the current working directory being set to any particular directory. If you have a path that you want to be relative to the sequence file path there are two options that I would suggest.

1) build an absolute path to your file at runtime based on the sequence file's path and your relative path. Both can be gotten programmatically at runtime via expressions or the TestStand API.

Or:

2) Use TestStand's builtin file path search directory feature, FindFile, either via the API or an expression function. By default, if pass the current sequence file parameter to FindFile it will check the current sequence file directory first before looking in the other search directories.

Hope this helps,

 -Doug

[Mac671]

Hello Doug,

And thanks for the prompt reply. 

Your reply does give me the basis for a work-around.

I've implemented this based on your suggestion, from point #1, it and it works, so Thanks.

To answer the "Question if the path was a parameter to my own code?"

The answer is yes, but I use the same guidelines as MS SDK functions. 

To answer your question as to "What am I doing with the path?", I'll send an example to illustrate. 

The sequence in the attachment will:

1) Pass when I open it form File->Open  than navigate to the file and run it.

2) Fail when I. Close TestStand, Open it again, and open the file while using the recent files shortcut form the File menu.

Your explanation that I shouldn't rely on the working directory seems to be valid here. 

For me this just isn't very intuitive, as I had assumed that TS will try and search for the file in the same dir, or relative location to it's sequence file, in the given scenario.  

Thank You,

Maciej 

[dug9000]

TestStand does check the current sequence file directory by default for paths you specify as code module paths using the normal TestStand search directories algorithm. But in your case you aren't giving the path to any TestStand code, you are just passing the path into a Microsoft written dotnet function, System.IO.File.Exists(). TestStand has no control over how Microsoft's function treats relative paths (apparently it uses the current working directory as most Windows SDK functions do). Also, in your use case you probably don't want to use the full teststand search directories algorithm because that will check for the file in other directories besides just the current sequence file directory if it doesn't find it there so building the absolute path with the sequence file's path is probably the best thing to do in your use case.

So in summary

1) TestStand does generally look in the current sequence file directory and other search directories for relative paths that you give to TestStand.

2) You are not giving this relative path to TestStand you are giving it to Microsoft's System.IO.File.Exists() function. This function appears to assume that relative paths are relative to the current working directory.

Hope this helps clarify things,

-Doug

[dug9000]

Just want to add that if you do want to look for your file using the standard TestStand search directories algorithm then you should just use the FindFile() expression function in a statement step instead of calling System.IO.File.Exists(). But I'm not sure if that's what you want in your use case.

-Doug

[Mac671]

I used the RunState.SequenceFile and extracted the path property value from it.

I just stripped that property of the seqfilename with a little tiny bit of scripting, and this way I got the absolute path, and it works for me now.

The System.IO.File.FileExists() call I used in the seq file attached just show an easy .NET call, that I coud use with the pass/fail adapter, as I din't want to send pieces of my production, awesome sequence 🙂

Thanks,

Maciej