How Can I Open an Alternate Application Context

[paul_cardinale]

I am working on a very large and very complicated application. It will be built into a .exe file. One of the functions it must perform is to load and execute a suite of external VIs. I am concerned about potential name clashes. Although it will be guaranteed that the VIs that are explicitly loaded will be owned by uniquely named .LvLibs, there are no guarantees about the names of the dependencies of the dynamically loaded VIs. So in order to make the system as robust as possible, I want to load the dynamic VIs in a namespace that is separate from the caller (i.e. a different application context). I’ve come up with a couple of solutions, but I don’t like either one, and I am hoping someone knows a better way.

One solution is to create an app (built to a .exe) that uses an alternative VI Server port (3364) and does nothing except hold a memory space. My main app can start that .exe, open an application reference to it, and use that for loading the dynamic VIs. This works OK, but it’s very klunky.

Another solution is to use one of the several application contexts that are already open in the main app. This works for now, but is unacceptable because I can’t find documentation on these contexts. Here are the names of the contexts I find in a running .exe:
  Main Application Instance
  NI.LV.NoVIs
  NI.LV.Editor
  NI.LV.AutoLaunch
  NI.LV.PlugIn
  NI.LV.ClipVI
  NI.LV.NewCtl
  NI.LV.CCallVI
Is it known whether it’s OK to use any of these other than the “Main Application Instance”?

Is there a clean way to open a new application context?

[wiebe@CARYA]

I wouldn't be surprised if, in an executable, each loaded packed library gets it's own context. I'd start by exploring if that is the case. If so, simply using packed libraries would do exactly what you're trying to do, but in a build in way. This is what packed libraries are supposed to do...

During editing, each project gets it's own context. IIRC, You can open VIs in their project in the executable, by calling the command line with the (quoted)  project path and then the VI path. I'm not sure if that's an option. You'd need to distribute source code, and include all used sub VIs, including vilib VIs.

There are two brown nodes, "Context.Open Sibling" and "Context.Create Local Host App Instance". Despite it's name, Open Sibling appears to create a new sibling context... Never used them... Usually these nodes add more problems than they solve.

[paul_cardinale]

This is the only thing I could get to work (and it's all brown).

[wiebe@CARYA]

That is the best documented brown node I've seen.

[paul_cardinale]

Interestingly, if I turn off SuperSecretPrivateSpecialStuff, then all those nodes show up as yellow.  But then the context help for them becomes: "No description available"