Forcing dependencies paths while packing an library

[nikodem]

Hi All,

Is there any way to force the packed library builder to use a dependency from an arbitrary place and NOT take it with itself to the packed library support files folder.

There is an library, that I am packing. Among all the things it depends on several things: one of them is a dll and another is an earlier packed library, that is located in C:\Windows\PackedLibrary.lvlib. When I pack the library it makes a support directory, where it stores the dll file (that's good) and the PackedLibrary.lvlib (which is bad). How can I force it to be dependent on the lvlib in C:\Windows?

[Norbert_B]

Which version of LV are you using?

2016 provides the option to exclude shared libraries (dlls) and packed libraries during build which prevents duplication in/at the data-folder (tab: Additional Exclusions in the build script of the PPL).

[nikodem]

LV 2014 SP1 😞

Is there no other way to force it to use the LVLIBP  from C:\WINDOWS instead of copying it to their own support directory?

[Norbert_B]

http://forums.ni.com/t5/LabVIEW-Development-Best/Plug-in-Architecture-using-Packed-Project-Libraries...

[nikodem]

Unfortunately I cannot use this architecture - has to stick with normal LVLIBP that is in the C:\Windows directory (this is an error handler used in many of modular projects in our company). Is there no other options? 

[Norbert_B]

You can define additional target destinations for sources in the Application Builder. Sounds like you should perform the following steps:

1. Build the PPL in a separate project (as before)

2. Include the PPL in your project for the EXE

3. In the build script for the EXE, create a new destination. Bad thing here is that you have to select a absolute path for Windows-directory

4. Assign the PPL to the Windows-directory based destination

Running the script will put the PPL into Windows-directory based destination and make sure that the EXE is looking there for it.

However, the biggest catch is that you are bound to that absolute path for this PPL dependency. If you put the EXE on a system where e.g. Windows is installed on D:\ instead of C:\, your application will fail to find the PPL.

EDIT: All in all i discourage you to pursue this approach. A PPL is functional comparable to a DLL, but it is not meant to be used like a system component like a lot of DLLs are used. Additionally, LV doesn't look into e.g. Windows\System32 for components like most textual languages (e.g. C/C++) do. That is why you require the absolute path i mentioned above.

[nikodem]

This is almost perfect. Now the only problem is the fact, that this demands the builder app to have privileges in the system in order to modify files in C:\Windows.  As I'm building this from Jenkins this is a bit problematic, but that's not a show-stopper...

EDIT:

Okay, this is a show-stopper:

Cannot build the application because the following source files are in the destination directory. You must build the application to a different directory from the source files.

C:\Windows\Error_Generator.lvlibp

Dang 😕

[Norbert_B]

Seems that you are running into constraints of Windows. I am not sure about C:\Windows itself, but for instance C:\ProgramFiles is 'protected' for custom access.

That means that installer can put files in there, but for adding/removing files manually, you require administrative rights. I can imagine that the same is true for C:\Windows.....

What is the purpose of placing the PPL there? Is it not possible to move to ProgramData or <User> directory instead?

[nikodem]

No, the problem is that the error handler library is already there before I start my build, so the build tries to overwrite it while reading from it...

The file has to be there, I can't force the whole organization to change this to somewhere else - too much projects use this, and it's there due to... "historical reasons" . So, any idea? 😄

[Norbert_B]

---

@nikodem wrote:

[...] I can't force the whole organization to change this to somewhere else - too much projects use this, and it's there due to... "historical reasons" . So, any idea? 😄

---

This, i do not understand. If there are already projects using this: Why is it suddenly an issue (and not from the first project on)?

Also, there must have been a solution to this in the past... what was it? Why does it not work anymore?

If you are able to update LV, you can select the option i stated in my first reply. 2014 obviously doesn't have that option (at least from your posting), so there is no technical solution right away.

Finally, breaking recommendations and guidelines from the OS vendor is always a bad idea. Using tools from another vendor which do then run into certain limitations because of the 'breaking the rules' issue, it is not really the fault of the vendor. It is a flaw in the process how you work with the tool. And i do recommend to rethink the process in the first place.