Packed Library Type Defs - Best Practice?

[LuminaryKnight]

I've created a data parser and built into a packed library for easy distribution and plug and play updates.  However, one item is giving me a headache and I do not know how to manage it and I was curious the community's thoughts on best practice.

Type Defs.  The output of the parser is of course unique and I've made a type def.  But when distributing the packed library, users can only pull the type def from the packed library.  However, if they go to build their applications, unless that packed library is exactly where it was during dev, the application spits up a search window looking for the control.  For now, I tell people to put the control onto their block diagrams and then disconnect it from the type def as a temporary work around.  However, if this type def were to ever change (which it has and I suspect will continue to do so), I do not want users constantly having to replace their disconnected controls.

So what's best practice for this?  How do I distribute this and make it as easy and painless as possible?

[tyk007]

If it is being distributed for use within the dev environment or a built application, I would instead favor using a VI Package for this particular use case. I tend to only use packed libraries if I need a stand-alone component at run-time.

[LuminaryKnight]

---

@tyk007 wrote:

If it is being distributed for use within the dev environment or a built application, I would instead favor using a VI Package for this particular use case. I tend to only use packed libraries if I need a stand-alone component at run-time.

---

A lot of our tools we're making are focusing on updating single pieces.  The same packed library is used in different applications.  So instead of updating each application because data parser might change slightly, we just change the parser and distribute.  Seems cleaner and smoother.  But yeah, the minute the type def changes, BOOM

[tyk007]

---

@LuminaryKnight wrote:

---

@tyk007 wrote:

If it is being distributed for use within the dev environment or a built application, I would instead favor using a VI Package for this particular use case. I tend to only use packed libraries if I need a stand-alone component at run-time.

---

A lot of our tools we're making are focusing on updating single pieces.  The same packed library is used in different applications.  So instead of updating each application because data parser might change slightly, we just change the parser and distribute.  Seems cleaner and smoother.  But yeah, the minute the type def changes, BOOM

---

I have built PPLs that depend on PPLs. As long as the prerequisite is in the same folder or sub-folder to the calling PPL, then I have never had an issue with finding that dependency with the run-time engine.

When you say building their applications, can you clarify what you mean? Packed Library? Executable? Dev Environment? VIs with block diagrams removed? Other?

[jyoung8711]

This is a bit of a loaded question, and the answers change depending on what your environment looks like.

One "quick way" to solve this, is this:

If the secondary "applications" are built (EXE/dll/.NET/PPL) and are ONLY using this type def (ie not calling anything else from the ppl) then when you build the application, you can uncheck the "Disconnect type definitions" button under Additional Exclusions in the build spec (screenshot below).  If the only dependency is the type def, then the reference to the PPL will then be excluded.

If there are dependencies, then you'll have to distribute the PPL with the built application. Where that needs to do depends on how you built the application (whether you "excluded dependent packed libraries" or not) the PPL will either be referenced relative to the final build (not excluded), or absolute (excluded).  Again it kind of depends on the details/desired outcomes.

For my dev team, we distribute re-use PPLs via VIPM and they live in vi.lib.  When we build applications, we include them with the build, and put them next to the application we built.  This is not the only option.  There's another strategy where PPLs ALWAYS go to the same place on the computer "C:\MyPPLs" and everyone always references the PPLs statically there.

That might be more detail then you wanted, so to come back to the original question: If you're truly only referencing that type def... then enabling the checkbox below will solve your issue.

[LuminaryKnight]

I guess the more I think about it, the issue lies in the folder structure of the dev environment vs the distribution.  Spent hours resolving one co-workers' Packed Library dependency issues as he had absolutely no folder structure when he developed.  So then when he placed Application.exe at wherever, nothing worked.  Even dumping all Packed Libraries into the data folder didn't resolve.  Packed libraries calling packed libraries feels like a cardinal sin for that very reason.  Cuz when time comes to distribute, the packed library depending on a packed library needs that packed library to be in the proper place or else.

Anyways, I think I've gotten my answer which is... it is what it is.  If the type def updates, co-workers gonna need to update their executables anyways.

[jyoung8711]

Yes, you have to be pretty organized when doing development with PPLs.  However, PPLs depending on PPLs is completely fine and very viable.

I have two very large projects when have large PPL dependency chains.  One has >100 PPLs associated with it, and the other has >50 PPLs.  Both support dynamically loaded plugins as well as "common code" dependencies. 

The trick is that all PPLs have to stay in the same relative position to each other, and the applications have to pull that dependency hierarchy into a meaningful location. 

Or, like I said, the other options is to ALWAYS build ALL ppls to the same location on disk, and always select "Exclude dependent packed libraries" on build specs.  I prefer the former, because I wanted to be able to update dependencies dynamically on a per application basis, rather than for the whole system at the same time.