How to include image files and dependant DLL in LV 2010 installation.

[davemnicholls]

So two problems with creating an installation for my application.

First:

I have a report generator that uses a company logo from a png file.  I have this in a folder relative to the .exe.  It works fine in development but the installer doesn't automatically include the png file and I can find no way to tell the installer to just include it in the distribution.

Second:

The aforementioned report generator requires a couple of DLLs that are shown as dependencies.  One of them gets included in the build, the other doesn't!  If I manually copy the missing one then it works.  What can cause an identified dependancy not to be included in the installer.  Again there seems to be no manual way of including the file either.

Dave.

[Taki1999]

Have you included the png in your Project?

You should be able to add it just like any other text or graphics file and then it should be available as a source file when you build your installer using application builder.

You may want to consider using the Get System Directory function in order to generate a uniform path to the .png across different OS'es.  I think there are some Windows 7 issues with pathing from the Program Files directory instead of the Application Data directory.

Same with the .dll.  Add it into your project explicitly.  (i.e. not in Dependencies)

[rolfk]

For 1) you need to add the file first to you project and then in the Executable Build Specification you can add it to the Build Tree, define it's target location and set it to be always included (should be default for non-LabVIEW file). This file should then be automatically included by the Installer too.

For 2) the general and technical answer is that one DLL seems to be specified in the Call Library Nodes by its entire name and the other not. The more important information is what Report Generation interface are we talking about here? The missing DLL alone may not really be enough but could be part of a (runtime) installer for that Report Generation Library.

[rolfk]

---

@Taki1999 wrote:

You may want to consider using the Get System Directory function in order to generate a uniform path to the .png across different OS'es.  I think there are some Windows 7 issues with pathing from the Program Files directory instead of the Application Data directory.

---

The issue under Windows 7 is, that an application has normally no write access to that directory. Since this only involves reading the file and not modifying it in any way, this should be still completely ok under Windows 7 (and Vista).

[davemnicholls]

I think one of the DLLs was calling the other, so the one used directly by a vi was automatically added whereas the other wan't, even though they were both in the dependancies and they are both in the same original source location.

I've just included both the missing files in the project and now the installer is working correctly.

Thanks chaps.

[rolfk]

---

@davemnicholls wrote:

I think one of the DLLs was calling the other, so the one used directly by a vi was automatically added whereas the other wan't, even though they were both in the dependancies and they are both in the same original source location.

I've just included both the missing files in the project and now the installer is working correctly.

Thanks chaps.

---

As far as I know, without debugging trickery or parsing the import table of a DLL themselves an application has no way to detect that a DLL depends on another DLL.

[davemnicholls]

---

@rolfk wrote:

As far as I know, without debugging trickery or parsing the import table of a DLL themselves an application has no way to detect that a DLL depends on another DLL.

---

That makes sense.  I think the confusion is that it was showing in the dependancies.  It's probably the case that it picks up on the DLL it can see, and then lists everything else in the same folder rather than perhaps more intelligently only listing the ones it can really detect in the application.

[rolfk]

---

@davemnicholls wrote:

---

@rolfk wrote:

As far as I know, without debugging trickery or parsing the import table of a DLL themselves an application has no way to detect that a DLL depends on another DLL.

---

That makes sense.  I think the confusion is that it was showing in the dependancies.  It's probably the case that it picks up on the DLL it can see, and then lists everything else in the same folder rather than perhaps more intelligently only listing the ones it can really detect in the application.

---

Not in my experience. LabVIEW is pretty smart in this. Sometimes to smart. But I'm also pretty sure that it does not resort to parsing the import section of a DLL, and debugging trickery is out of question anyhow as that can only be done with full administrative rights.