.net retain static variable during multiple vi runs

[Joshua123]

I have a .net c# dll containing a class with a static variable, like below.

public class Class1
{
  static int value = 1;

  public Class1()
  {
  }

  public int incValue()
  {
    value++;
    return value;
  }

}

When i run the incValue method multiple times in c# i get 2,3,4,5..etc as result, as expected.

When i run this method inside a vi, by multiple times running the vi, i always get 2.

Why ?

And how to make it work as expected ?

[Joshua123]

some more info

Labview 2012,  12.0.1F1 (32bit)

Windows7 (32bit)

After closing labview and freshly opening the vi, but not yet running, the .NET Assemblies in memory shows the dll is already in memory!!!!!

[.aCe.]

---

@Joshua123 wrote:

some more info

Labview 2012,  12.0.1F1 (32bit)

Windows7 (32bit)

After closing labview and freshly opening the vi, but not yet running, the .NET Assemblies in memory shows the dll is already in memory!!!!!

---

This is normal behaviour, LabVIEW loads the dll because of the constructor in your block diagram. So that is not related to your issue.

Why do you need it to be static?

http://stackoverflow.com/questions/10795502/what-is-the-use-of-static-variable-in-c-when-to-use-it-w...

[Joshua123]

This is normal behaviour, LabVIEW loads the dll because of the constructor in your block diagram. So that is not related to your issue.

I completely agree.

But static variables should remain valid during the lifetime of the dll in memory.

They get initialized 'somewhere once', after load time.

Thats why i'm stumped in whats happening.

The only way i thought i could explain the behaviour is by labview loading/unloading the dll each time the vi was run.

But the assmblies in memory shows it remains loaded.

[Joshua123]

Why do you need it to be static?

To maintain an internal database, that needs to be shared/updated among different function calls, even over vi's.

[.aCe.]

Can you try closing the constructor reference you opened please?

[Joshua123]

Can you try closing the constructor reference you opened please?

I started with a closing reference, but removed it to check if that would make a difference. 

Anyway, i re-did it.  And no change.

[tst · Accepted solution]

I'm not a .NET programmer, so I'm not familiar with how these behave in C#, but I'll bet this is because you're starting and stopping VIs. When a top level VI in LV stops running, all the references which were created under that VI are automatically destroyed, and that should include .NET objects. I'm guessing the static variable is reset either when all instances of the class are destroyed or that there's some magic general call for the interface between LV and .NET which says "I'm starting/stopping".

This should be easy enough to check by having a loop with an event structure to create the objects rather than just running the VI once (which is how I expect your actual application will also behave). You can also use to check whether this reset happens if all instances of the class are destroyed by calling the relevant destructor and/or the close reference function.

[Joshua123]

I have single stepped the vi below while the visual studio debugger was attached to labview.

At 'Construtor node', the debugger hit the breakpoint at '\\ 1' then '\\ 2'.

At 'invoke node' the debugger hit '\\ 3'

re-running the vi showed the same sequence 1, 2, 3

Using visual studio, the 'button1-click' activated 1-2-3, then every next button click activated 2-3. As it is supposed to.

[tst]

Like I'm said, I'm not a .NET programmer, so there's probably something I'm missing - I see that you define a form and you define an event for the button, but I'm missing the loop which sits and listens for those events or at least represents the lifetime of the application (assuming the event is simply a callback to the defined function). Is that something built into the form or just some code that you didn't show?

Also, did you try what I suggested about a VI which doesn't stop? Ultimately, that's what you will need as that represents an actual application.

Like I said, it's also possible that there's some magic behind the scenes about starting and stopping, which happens in LV, but doesn't happen in .NET.