have to re-select .net assembly file every time I launch TestStand

[DelProtin]

I have created a .NET object to handle a custom database application.  When I set up my TestStand sequence step it works, however the next time I open TestStand it fails to call the object, but does not give me any errors.  To get it working I have to re-specify the .net module.  To do this I open the step and select a diferent dll, save the step, open the step again, re-selct the original dll, save the step again, and now everything works again. 

Additional info:

I am selecting an assembly (not a global assembly), providing the full path to the object.

I store an object reference for use in future steps.

In the same step that I instantiate the object I am calling a Method to verify that it is alive, returns a boolean is alive.

[Ecleamus]

Hi DelProtin,

A few questions for clarification:
1.  When you say 'it works,' does that mean you can run it multiple times with no problem and you only have a problem when you close TestStand and open it back up?  I assume that this is not the case since closing TestStand should not impact the step.
2. How are you storing the object reference for use in future steps? If you are using a station global, that will not keep the object reference value after you close and re-open TestStand. 
3. You mentioned that the step fails to 'call the object' but produces no error.  Do you mean that the object reference is created or not?  One way to check is to put a breakpoint and check the local object reference (in the context tab) before and after the step is called.

One other thing to try is to see what behavior you see when you select File->Unload All Modules.  From the offset, it sounds like something is not being let go by your .dll but I need more information to know for sure.

Have a great day,

Ecleamus Ricks, Jr.
National Instruments
Applications Engineer

Message Edited by Ecleamus R on 09-21-2006 04:44 PM

[DelProtin]

Ecleamus

When I same it works, it works.  I store the reference in a local parameter that is feed back up to a global when the callback returns.  This global is then passed to all other callbacks that need access to the .net object.  So when it works, all calls to the object work.  I can run the sequence over and over again with no issues.

So I already answered question 2 I do store it in a station global and it does go away when I close test stand.  However even before that, at the end of the sequence, I dispose of the object and set its reference to nothing.  I do this because the object uses a license for a piece of commercial software that I want to release.  In this way the object ties the license up for about 30 seconds to a minute, it is then released and disposed of.  So yes every time the sequence is run, I have to re-instantiate the object which is why I am baffled that once working it will work all day long, but I have to kick start it every time I open TestStand.

As far as producing no errors, the object appears to be instantiated because I get a .NET reference.  However in the same step I instantiate the object I call a read only property that simply returns a TRUE.  When it works I get a TRUE, but when it doesn't I get a FALSE.

As for Unload All Modules it has no effect.  When it is working it stays working, and when it is not working it is not fixed by unloading all modules.

While experimenting last night, I uncovered an interesting clue.  I have 2 copies of this .NET dll on my system.  The first is in the Visual Studio directory, and the second is in the TestStand directory \Components\User\Models\TestStandModels.  I have been pointing to the one in the TestStand User Model directory.  Last night just for fun I pointed to the one in my Visual Studio Directory.  I closed and reopened TestSTand and all worked.  I repointed to the one in the TestStand User Model Directory and I was back to needing to kick start.  I am assuming this to be because of Registry entries confounding the facts.

I was working this way so that when I deployed the new TestStand model, everything would be where it was on my development system.  Since I am getting close to deploying it, I need to resolve this.  The true test will be when I put it on a test station will I have the same issues.  Any thoughts

TIA

Del Protin

[Ecleamus]

Hi Del Protin,

My first thought is you shouldn't see this behavior on the test machine if you only have one copy of the .dll on the station. I assume you will be able to confirm that for me.

My second thought is about possible causes.  I strongly recommend you do not copy the .dll to the Models directory.  One reason that I think is the cause of the behavior you're seeing now is because of search directories ordering.  Are you using this dll in your process model? Where's the Visual Studio directory in your search directory ordering? Another question, how have you specified the module (absolute path or relative, if relative how?)  These are all possible contributors to this behavior.

Have a great day,

Ecleamus Ricks, Jr.
National Instruments
Applications Engineer

[DelProtin]

As soon as the test machine is up I will confirm if I have an issue.

Yes I copied the dll to the model directory, this way I would always have the last working one while I enhance and debug the one in Visual Studio.

As for the search directories, I have not modified them from the default.  Which means I did not add the Visual Studio Working directory into the search directory list.

I specified the module as both relative and absolute, and it made no difference.  I have assumed that I really want it to be relative, this way if Test Stand is installed in a different drive or directory, it will still work since it is a relative path.

The dll is the core behind all the changes I am making to the process model.  The function of the dll is to deal with a database for doing realtime spc and knowledge based diagnostics.

[Ecleamus]

Okay, I will ping R&D in the meantime for other possible causes. 

Have a great day,

Ecleamus Ricks, Jr.
National Instruments
Applications Engineer