Feedback request - Packaging and distributing your project provider with VIPM

[vishots.com]

We'd like to make VIPM, the best tool it can be for distributing your Project Provider LabVIEW add-ons. Please provide feedback as to the issues you are facing when distributing your project provider tools. How can VIPM help make the experience better?

Some questions to get the conversation started:

• What tool are you using to distribute your project provider?
• What are the difficulties in packaging or distributing project provider tools?

Please provide any feedback you can. We want to support building project providers with VIPM, and your feedback will help in this.

[Mattias_Ericsson]

Hi Michael,

It sounds great that VIPM is going to have support for project provider tools. Here are my experience with the project provider distribution:

• What tool are you using to distribute your project provider?

[ME] We have a simple LabVIEW installer VI (just one VI) that just copies the files to LabVIEW installation folders and then masscompiles the installed code when it at the correct place. Tried to make a VIPM package, but haven't succeeded.

• What are the difficulties in packaging or distributing project provider tools?

[ME] It is hard to masscompile it outside LabVIEW environment since <resource> folder is not a symbolic path and causes new unwanted relative links if our VIs is masscompiled outside the LabVIEW/resource environment.

Thanks,

Mattias

[MikaelH]

Hi Michael,
We got it working just fine for GDS.
Using the Pre-Post Install/Uninstall VIs solved our problems.
We also check VIPM's ini file to see if Mass Compile after installation is checked.
If so we warn the user that this extra task takes about 20 minutes or so.
That's why we have pre-compiled GDS for all LabVIEW versions for Windows.
Because if one file of the Provider VIs needs to compiled when LabVIEW starts up, that could cause LabVIEW to crash completely, especially the 64 bit versions.
Cheers,
Mike

[EricLM]

I am wrestling with this right now as well.

When I try to build a provider from its location in resource\Framework\Providers, I get an error saying that files cannot be named the same as those in the LabVIEW hierarchy.

When I try to build from another location, I get errors either that callees are missing or it builds correctly, but the installed files are missing callees (specifically from API and Common).

Mike, how did you get around this with pre-install and post-install? Did you load the files from API and Common into memory before the mass compile?

I cannot seem to get the linking right, but I would really like to use VIPM to distribute our tool. Any help would be appreciated.

Thanks

Eric

[vishots.com]

This is easier in LabVIEW 2012. What version are you using?

[Mellroth]

When packaging project providers (and other code as well) I would really like to see an option to just copy the source files, i.e. do not recompile before packaging (like OpenG Package builder).

/J

[jgcode]

Mellroth wrote:

When packaging project providers (and other code as well) I would really like to see an option to just copy the source files, i.e. do not recompile before packaging (like OpenG Package builder).

/J

http://ideas.jki.net/topic/55099-option-to-skip-compile-of-vis-during-build/

[Mellroth]

I guessed there was a post about this allready, and we do have a similar workaround (we rename the files to have different extentions in pre- and post install scripts.).

/J

[EricLM]

Michael_Aivaliotis wrote:

This is easier in LabVIEW 2012. What version are you using?

I am trying to build in 8.6. What about building a package in 2012 is different than 8.6?

[TCPlomp]

I have an extension to the SCC provider that I install with VIPM.

However there is an issue if the provider is calling a DLL. Since the DLL is locked it cannot be overwritten by VIPM (even if the DLL is of the same version)..

After a failed install I have to restart LabVIEW, then reinstall the provider and then re-enable the SCC provider.

Ton