SubVIs called by VIs built into a DLL must be located when opening a VI that calls the DLL

[Dr_M]

I have built a DLL that contains two exported VIs that call subVIs that call another DLL containing hardware dongle functions.  The DLL build works fine and the two VIs work fine as source code.  The reason I want to build a DLL is avoid distributing the dongle source VIs in order to make the two functions calls more secure.  However, when I try to open a VI that makes a call to one of my two DLL functions (exported VIs), LabVIEW tries to find all the subVIs called by the exported VI that was in the DLL.  This suggests that the DLL does not contain the subVIs - surely every VI called by the exported VIs should be built into the DLL - or am I completely wrong?  I have tried setting all subVIs and the dongle DLL as "always included", and even exporting all subVIs too.  Is the DLL builder capable of including the entire VI hierarchy in the DLL?  Am I missing a special combination of settings?

To summarise my process:

A top-level VI (to be supplied to an end user with password protected diagram) calls my DLL (two functions are exported VIs) which call subVIs which call the dongle DLL.  I only want to supply my DLL and the dongle DLL, NOT any related source code.

Any help would be greatly appreciated, as this problem has completely stopped my development.

Mike

[Dr_M]

Forgot to mention that I am using LV 9.0f2 and Win XP.

Mike

[Dr_M]

I have also just noticed that when I build an application, the exe cannot find any subVIs either - same problem as the DLL build.  Could it be that my application builder is corrupt?

Interestingly, a project that I upgraded from LV8.6 contains an application build that works properly.  It just seems that any brand new project application or DLL does not build correctly.

Mike

[Dr_M]

I have attached an example project containing a single top-level VI and a single subVI.  The executable that I have included asks for the location of the subVI when it runs.  This proves that the subVI is either not located within the executable, or the executable has lost the path to the subVI.

Can anyone else reproduce this by building this executable on their own system?

Mike

[Dennis_Knutson]

When I did a build, I had no problems. The subVI is part of the exe and there was no prompt to find it.

[Dr_M]

So does that mean I have a problem with either my application builder or run-time engine, and if so, where is the problem and how do I go about fixing it?  I have already tried repairing LabVIEW.

[Dennis_Knutson]

I'm not sure what could be wrong. All that I did was refresh the project to link to the top level because it was in a new location and then I did a build.

When you open the top level, do you get an indication that it needs to be saved (i.e. an * is showing on the title bar)? What about the project when you close the top level? After doing a build, you should be able to right click on the 'My Application' and select Explore. When you go to that folder and double click the 'application.exe', do you still get the prompt to find the subVI?

[Dr_M]

The top-level VI does not need to be saved again after opening it, and neither does the project.  When I explored to the Application.exe and ran it, it still prompted to find the subVI.  I am having the same trouble with another application build, where the executable cannot find a single subVI, including any lv.lib VIs.

My Application.exe is 171 KB in size.  Is yours the same size?  A difference in size may indicate the presence of the subVI or not.

I have made a larger subVI with an array constant and front panel array data.  When I build this time the new Application.exe is 209 KB.  What about when you do it?

[Dr_M · Accepted solution]

After browsing through the LAVA application builder forum, I found a post that discussed a build problem relating to the Advanced setting "Use LabVIEW 8.x file layout".  This must be checked to make the build work.  Apparently R&D already know about the problem (# 158487).  Also, previous 8.6 projects will have this checked by default, which makes them build correctly.

The new application now runs correctly.

The original DLL build problem is also fixed.