.net retain static variable during multiple vi runs

[Joshua123]

This should be easy enough to check by having a loop with an event structure to create the objects

To check your theory, i have created the following situation

As you can see, the outcome now is 3.

Re-running the top level vi results in 3.

So the conclusion is that labview detaches all references when the top level vi stops running.

This is a design decision, which i cannot argue with. It fits in the labview way of thinking.

The reason i designed my dll in this way, was beiing able to run 'a' vi (at that time beiing a top level vi) to initialize a lot of stuff (which takes a minute or so).

Then use other vi's (beiing top level vi's at that time) to use the 'already initialized stuff'.

Since it is not goiing to work in this way, i need to go for 'plan-b', the better, but 'a bit harder' way.

Thanks for helping out.

[tst]

Well, I think plan A only makes sense if you don't treat LV as an application development environment and you're willing to have the user (even if that's you) run VIs as part of the normal sequence of operations. I sometimes do that for various development utilities which I use, where polish doesn't matter and I'm fine with running VIs, but for every single application I create, I treat it exactly as I would if I was writing it in C - it's built into an EXE and the user never sees anything that's related to LV - the toolbar is always hidden. That seems to me to be the only sane option, so that should be plan A.

[tyk007]

When your top-level VI runs, LabVIEW creates an AppDomain to host all your .NET objects. LabVIEW pins your .NET objects in memory so that it can always locate them despite garbage collections - this is a feature of the CLR hosting.

When the top-level VI finishes and unloads, the .NET objects are un-pinned and the AppDomain is removed. This is because the LabVIEW application has finished.

Since statics are only unique (well, static) per AppDomain this is why you see the behaviour you do.

Most .NET applications do not make use of multiple AppDomains and all run in the default one created by the CLR on loading, hence why you may be confused as to the behaviour.