Controlling when project dll's are loaded?

[Daklu]

When I open a project in the LV dev envrionment that makes calls to a dll via the Call Library Function node, I can control when LV loads the dll by setting or clearing the "Specify path on diagram" option.  Setting it loads the dll when the vi executes; clearing it loads the dll when the project is opened (or more specifically when the vi is opened.)

Is there a similar way to postpone loading ActiveX or .Net dlls in the dev environment until the vi executes?  I suspect not given the interactive nature of those dlls in LV... but what the heck, it never hurts to ask.

[Kristen_K.]

Hi Daklu,

While dynamically loading AcitveX and .NET objects is not a feature of LabVIEW yet, there is a concept of shadowing copying.  There is a good explanation in this thread.

I hope this helps!

[rolfk]

Another option to what Kristen mentions is to actually invoke the VI(s) that has/have the ActiveX or .Net nodes in its diagram dynamically. Basically you write a wrapper VI that Opens and Calls by Reference the actual VI through VI server and include that wrapper VI in your code. You can also implement that wrapper as a LabVIEW 2 style global to allow speeding up subsequent calls, by storing the VI refnum in a shift register, and skip the loading of the VI for all subsequent calls.

Message Edited by rolfk on 03-24-2010 02:54 PM

[Daklu]

I don't think shadow copying helps my particular pain point.

The root issue I'm trying to address is using 3rd party ActiveX and .Net dlls in conjuction with source control.  We have been keeping the dlls in the project source control tree to make it easier for developers to make sure they have what they need to work on the project.  However, both the .Net constructor node and the ActiveX constant appear to use absolute paths to locate the dll, which becomes a problem when everyone maps the repository to a different location on their local computer.  The new path is usually found but it triggers a recompile and LV constantly wants to resave those vis with that depend on the path.

I can get around this with c-style dlls by specifying the path on the diagram and storing the dll in the same location as the rest of library.  I'm still trying to figure out how to handle the ActiveX and .Net dlls.  Rolf's suggestion solves part of the problem--the resave nags--in exchange for amplifying another problem--the code that actually calls the dll is not part of the project.

I've been trying to avoid modularizing the code to the extent Rolf suggests primarily because I was hoping for an easier way to deal with the issue.  Maybe the nature of ActiveX and .Net dlls is such that they require some sort of mechanism to distribute them to developers before using them in a Labview project if I don't want to deal with the recompiles?

[rolfk · Accepted solution]

---

Daklu wrote:

I've been trying to avoid modularizing the code to the extent Rolf suggests primarily because I was hoping for an easier way to deal with the issue.  Maybe the nature of ActiveX and .Net dlls is such that they require some sort of mechanism to distribute them to developers before using them in a Labview project if I don't want to deal with the recompiles?

---

Yes ActiveX and .Net are really meant to be registered (and hence properly installed on a machine). In that case the ActiveX or .Net using software does not need to know anything about the location of the actual component since it simply tells Windows to locate and load it. Registering of ActiveX happens truely by entries in the registry while for .Net you need to give them a strong version and put them in the GAC.

Unless you develop the ActiveX or .Net component specifically for the actual project and it is tightly tied to this project, you should not treat it as part of the project but simply document its dependency and install those components on all machines that your project should run on. Otherwise you also get trouble on the final building where you should install those components anyhow correctly istead of having LabVIEW magically bundle them into the support directory of your app.

The ability to reference an ActiveX or .Net component directly on disk is a convinience in LabVIEW but not one Microsoft really intended an application to have, but it has its problems as you have found out.

[Daklu]

Thanks Rolf.  This is an issue I've been struggling with for quite a while.  I've known the ActiveX and .Net components should be installed and registered on the target computer, but figuring out how to handle the components on development computers has been tricky.

Suppose you've written a reusable Labview class that provides an interface to a third party ActiveX/.Net dll.  How do you make the class and dll available to other developers in a way that the dll is registered correctly?  Do you create an installer for it?  Do you just drop it in a directory and make the developer register it manually via regsvr32 or gacutil?

Secondary question for anyone... do the installers you create in a Labview project automatically register ActiveX/.Net components with the OS?

[rolfk]

---

Daklu wrote:

Suppose you've written a reusable Labview class that provides an interface to a third party ActiveX/.Net dll.  How do you make the class and dll available to other developers in a way that the dll is registered correctly?  Do you create an installer for it?  Do you just drop it in a directory and make the developer register it manually via regsvr32 or gacutil?

Secondary question for anyone... do the installers you create in a Labview project automatically register ActiveX/.Net components with the OS?

---

I solve point 1 by simply trying to not do ActiveX or .Net at all if I can help it in any way  So far I have succeeded to avoid ActiveX or .Net entirely for functionality I developed myself. Writing a DLL is a little more work sometimes (well it would be if I knew very well how to do ActiveX or .Net) but doing a shared library gives me a lot more control, is a lot more lightweight and I always keep the option to port it to non-Windows platforms too, and have used that option frequently.

Point 2 has been solved by me because if I did ActiveX or .Net in the past it was always to a specific component of a customer. Since it was their software they wanted to keep control on it and did the entire installation stuff themself.