Error generating preview in Installer Properties

[LogMAN]

Hello everyone,

 

I recently installed LabVIEW 2013 on my development machine to get rid of some issues in my current project.

However the project is originally build in LabVIEW 2011, so I had to save all VIs for the new version (no issues )

I'm still able to build the application executable with no problems too!

 

Now I want to provide an installer for the customer to upgrade the Runtime engine and some additional stuff
that has been changed for LabVIEW 2013. And there lies my problem, as I'm currently unable to build an
installer. The configuration dialog shows 'error generating preview' for any executable in the project:

 

 

Naturally I tried to generate the preview in the executable, but there seems to be no issue:

 

 

Creating new specifications did not solve the problem and even creating a whole new project file and including
the startup VI to it + creating new specifications did not solve the problem...

 

I made a new project with a single VI for testing if the application builder is not working in general, but thats
not the case, as I was able to create an application + installer with no issues.

 

So I'm quite sure there is something wrong in my project that causes this behaviour, but I've currently no clue what that
could possibly be. I read somewhere (in the NI forums I guess) that there could be issues if you have files in your project
that are build in an older version (as one of the dll files), so I upgraded it... with no success...

 

Now does anybody had an issue like that in the past / currently and is there anything I could do or check to regain the ability to provide a proper installer?

What could possibly cause the installer dialog to fail generate a preview where the application dialog is successfull?

 

Any ideas are welcome

[hooovahh]

How much work would it be to recreate your project in 2013?  I ask because I have seen instances where a project file get corrupted or something, where it breaks and there is no explanation for it.  So I tried making a new project, then adding my code to it, making the Build Specification the same way the other was and it works.  Possibly something went wrong in the upgrade process from 2011.  I'm not saying this will fix it but if the project file it self is the problem this should help.

 

I just reread your post and it sounds like you may have tried this, you said "so I upgraded it... with no success..." what did you upgrade?

 

Also I never use the Generate Preview.  The last time I used it, it took just as long to generate a preview as it did to build the application.  Has it improved over the years?

[LogMAN]

How much work would it be to recreate your project in 2013?  I ask because I have seen instances where a project file get corrupted or something, where it breaks and there is no explanation for it.  So I tried making a new project, then adding my code to it, making the Build Specification the same way the other was and it works.  Possibly something went wrong in the upgrade process from 2011.  I'm not saying this will fix it but if the project file it self is the problem this should help.

 

I just reread your post and it sounds like you may have tried this, you said "so I upgraded it... with no success..." what did you upgrade?

 

Also I never use the Generate Preview.  The last time I used it, it took just as long to generate a preview as it did to build the application.  Has it improved over the years?

 

Hi hooovahh,

 

Well I use a DLL file in my project that has been created in LabVIEW 2011. This should be no issue, but would have made my application to load both runtimes (2011 for DLL & 2013 for EXE) so I managed to recompile the DLL in 2013. This is what I mean by upgrading "it".

As for the preview: If you create an installer, you want to tell it where to store the application files. For that the installer dialog will automatically generate the preview in order to provide the files list... I also want to provide a menu shortcut to the executable which I cannot create if there is no preview that includes the actual executable (it is basically as if it doesn't exist at all!).

 

The preview generator (in the application specification) is very quick for large applications.

 

Hi LogMan,

 

I had exactly the same symptoms when upgrading a project from 2012 to 2013.

 

After a lot of cursing and stripping my code back to the bare minimum I was left with a stupidly simple main VI that would build fine, and could create an installer. Adding a single VI to this would cause the installer to not generate the preview as you noticed, and also fail to build.

 

The VI that broke the camels back was a harmless utility from one of my re-use libraries (.lvlib). This library has a whole bunch of functions in it, and some of the VIs called some other libraries (obtained via VIPM) which I had not bother to install in my 2013 dev environment. Even though I was not actually calling these VIs from my main app (i.e. the main app was perfectly legit) the library was probably being loaded into memory when you do the file preview in the installer, and as there were dependencies missing it got confused.

 

So, to fix the problem I just needed to have all my dependencies installed, and the problem went away.

 

Edit: try a mass compile on your source directory, it will very quickly show you if you have missing dependencies.

 

Hi neil,

 

It seems I'm not the only one who had problems lately. Lucky me, as I now have an experienced bug tracker

 

I did as you suggested: I mass compiled all the project folder and cleaned up the orphan & bad VIs unless there was no error left, but still no improvement.

 

Here is what I did:

1. Mass compile project folder (returned some warnings about Bad-VIs & Missing VIs) -> Due to orphan VIs in my folder structure (removed!)

2. Mass compile project folder (still returned a bad VI) -> Removed it from my project library

3. Mass compile project folder (no error) -> Still can't see my preview in the installer dialog

4. Mass compile shared company libraries (no error) -> Still preview error

5. Clear compiled object cache (I use SVN, FYI)

6. Mass compile project folder (no error) -> Still preview error

7. Create a new project; add all necessary files; create an application specification; create the installer specification -> Does not work (preview error)

8. Mass compile vi.lib (did only take about an hour or so   & returned a bunch of errors -> masscompile.txt)

 

I did stuff like:

- Restart LabVIEW

- Reload Project

- Recreate Project

every now and then, but in the end there was still this <Error generating preview> text.

 

Well I'm ready for my weekend but if there are any more suggestions I would be happy to try them out!

Nice weekend to everybody!

Edited September 20, 2013 by LogMAN

[LogMAN]

Well, you could try what I did (as painful as it is), start pruning large chunks of your Main VI until you do get to a point where the installer preview works. Note you do not actually have to build the exe to check the installer preview. This may shed some light on what is the offending code that the installer builder does not like.

 

Also, try adding:

 

 NI_Appbuilder_logging=TRUE

to your LabVIEW.ini file. This will cause a text log file to be generated for all your builds, including the installer. Try actually build the installer even if the preview is nerfed, you should get some info from the logfile. The log file appears in the same directory level as your .lvproj file.

 

Good luck, this is such a frustrating thing to debug!

 

Thanks for the advice neil!

Where can I find the log file btw? (my build does abort instantaneously, so I'm just curious)

 

I found the VI in which the problem occurs (using your method). One of my VIs is very, very badly broken, but still executable

I can see the preview now, if I completely remove that specific VI from the dependency!

 

Maybe I'm halucinating here, but I'll now contact NI for further investigation and may update once I got answers.

Thanks for the support!

[hooovahh]

Thanks for the advice neil!

Where can I find the log file btw? (my build does abort instantaneously, so I'm just curious)

When I've used that INI key it makes the log file in the same directory as the project file with a .TXT file extension.

[JackDunaway]

I found the VI in which the problem occurs (using your method). One of my VIs is very, very badly broken, but still executable

I can see the preview now, if I completely remove that specific VI from the dependency!

 

Would you elaborate on what was broken? I'm intrigued.

 

(One of the usual suspects for code that works in the IDE but a build that fails is to check the hierarchy for Diagram Disable structures. If the structure contains disabled but missing SubVI, App Builder will fail. This is typical on EXE builds but not installers, so I'm curious to learn more about the failure mode you fixed!)

[LogMAN]

Would you elaborate on what was broken? I'm intrigued.

 

(One of the usual suspects for code that works in the IDE but a build that fails is to check the hierarchy for Diagram Disable structures. If the structure contains disabled but missing SubVI, App Builder will fail. This is typical on EXE builds but not installers, so I'm curious to learn more about the failure mode you fixed!)

 

Well the project is still broken. I know the part/VI in my project that causes the issue but I'm not sure why, so I'm currently in contact with NI to find a fix. I will surely post the solution once I know what is going on...

[hooovahh]

Would you elaborate on what was broken? I'm intrigued.

 

(One of the usual suspects for code that works in the IDE but a build that fails is to check the hierarchy for Diagram Disable structures. If the structure contains disabled but missing SubVI, App Builder will fail. This is typical on EXE builds but not installers, so I'm curious to learn more about the failure mode you fixed!)

Not just the disabled diagram structure.  I found one time where my code used the conditional diagram structure to do different things if it was in the runtime engine or not.  Both cases were executable and worked fine.  Then I changed the VI to be inlined.  The VI ran just fine in the development environment, but in the runtime engine case I used a property node which isn't allowed in a inlined VI.

[LogMAN]

Hello again!

I'm back to report the problem / solution.

 

The <Error generating preview> in the installer dialog is caused by a bad VI from one of NIs Toolkits! The Automotive Diagnostic Command Set in version 1.2.0 does update the compatibility to LV2013 and adds a new feature that causes my problem.

 

Thanks to neil   who made the suggestion to add an INI key to the LabVIEW.ini

NI_Appbuilder_logging=TRUE

The build log is created next to the *.lvproj file and directly shows the problem.

 

 

Where the IDE dialog just showed me an error: -1!

 

  !!! error -1 !!!

 

 

Here is the important line:

 

The file at 'C:Program Files (x86)National InstrumentsLabVIEW 2013vi.libAutomotive Diagnostic Command SetDiagnostic Transport.llbOpen Diagnostic on LIN.vi' was expected to have the qualified name 'NI_Automotive Diagnostic Command Set.lvlib:Open Diagnostic on LIN.vi', but has the qualified name 'Open Diagnostic on LIN.vi'.

 

This freaking VI forced me to clean up my project! ( I removed a whole bunch of orphan VIs, disabled structures, conditional structures, etc.. so it's good for the project )

As I'm unable to remove the offending VI from the library (password protected), I have to rely on NI to update the toolkit ASAP.

 

I hope this prevents anybody else to run into the same problem.

 

Thanks for the support and the helpfull suggestions, my project is now OCD conform

[hooovahh]

Thanks to neil   who made the suggestion to add an INI key to the LabVIEW.ini

NI_Appbuilder_logging=TRUE

The build log is created next to the *.lvproj file and directly shows the problem.

That is fantastic.  I wanted the INI key for a more detailed file list of what has been made in an installer.  I had no idea that it would give more detailed failure information.  I may do some testing on build time, and if it isn't much more I'm going to use this on all builds I do.

[CaseyM]

Here is the important line:

 

The file at 'C:Program Files (x86)National InstrumentsLabVIEW 2013vi.libAutomotive Diagnostic Command SetDiagnostic Transport.llbOpen Diagnostic on LIN.vi' was expected to have the qualified name 'NI_Automotive Diagnostic Command Set.lvlib:Open Diagnostic on LIN.vi', but has the qualified name 'Open Diagnostic on LIN.vi'.

 

This freaking VI forced me to clean up my project! ( I removed a whole bunch of orphan VIs, disabled structures, conditional structures, etc.. so it's good for the project )

As I'm unable to remove the offending VI from the library (password protected), I have to rely on NI to update the toolkit ASAP.

 

I hope this prevents anybody else to run into the same problem.

 

I recently ran into the exact same thing except my offending VIs weren't password protected so this thread definitely helped.

 

Does anyone know what mechanism causes VIs to lose their linking to their lvlib files?  I only noticed that it was happening when I came across this error.

[LogMAN]

I recently ran into the exact same thing except my offending VIs weren't password protected so this thread definitely helped.

 

Does anyone know what mechanism causes VIs to lose their linking to their lvlib files?  I only noticed that it was happening when I came across this error.

 

Unless you remove a VI from its library, it will stick to it, even if you try to load it without the library. However if you load a VI that is part of a library, you can disconnect it (File -> Disconnect From Library). I think there is also a possibility, to break the library, if you replace a VI of the library with one that is not linked to it (I have not tested this though). This is why I avoid to edit VIs while the library is not loaded.

[hooovahh]

This is why I avoid to edit VIs while the library is not loaded.

This is the best practice for sure.  I always start with a project, or a library.  Often times I forget about some kind of linkage that editing just a VI will cause issues with.  I like to bring up text based languages and say that if we were writing VB code would we take notepad and open some random file to edit?  No we would open the project first.

[JeffP]

Hello all,

 

I just wanted to let you know that we are aware of the issue described in the first post (the problem with builder an installer with certain VIs). In this case it is a VI from the automotive diagnostic command set library (CAR 429636). This is caused by a change in LabVIEW 2013 to the installer builder. There are two parts to this issue - 

 

1) If your project contains VIs in certain libraries, you are not able to build an installer that contains these VIs. There is no workaround for this and we intend to issue a LabVIEW 2013 f2 patch which will address this. (CAR 429282)

 

2) If your project contains VIs in certain libraries, you are not able to build a source distribution of those VIs. This is related to 1) but there is a workaround for this. If you go into your build specification Additional Exclusions and check the box for Remove unused members of project libraries you will be able to build fine. This issue will not be addressed by the patch.

 

I find that the appbuilderlogging INI token is extremely helpful for debugging build problems, the additional exclusions are often another good place to look at if you are running into strange build errors.

 

Thanks

[LogMAN]

Hello all,

 

I just wanted to let you know that we are aware of the issue described in the first post (the problem with builder an installer with certain VIs). In this case it is a VI from the automotive diagnostic command set library (CAR 429636). This is caused by a change in LabVIEW 2013 to the installer builder. There are two parts to this issue - 

 

1) If your project contains VIs in certain libraries, you are not able to build an installer that contains these VIs. There is no workaround for this and we intend to issue a LabVIEW 2013 f2 patch which will address this. (CAR 429282)

 

2) If your project contains VIs in certain libraries, you are not able to build a source distribution of those VIs. This is related to 1) but there is a workaround for this. If you go into your build specification Additional Exclusions and check the box for Remove unused members of project libraries you will be able to build fine. This issue will not be addressed by the patch.

 

I find that the appbuilderlogging INI token is extremely helpful for debugging build problems, the additional exclusions are often another good place to look at if you are running into strange build errors.

 

Thanks

 

Thanks for the update JeffP

I recently opened a new topic in the 'LabVIEW Bugs' forum to track the issue in the future (forget to post it here though )

http://lavag.org/topic/17166-error-generation-preview-in-installer-properties-caused-by-automotive-diagnostic-command-set-120/?hl=429636

 

The INI token is indeed very helpful, but unfortunately very difficult to discover (If it wasn't for Neil I would still be stuck...).

[JeffP]

Hi,

 

To close the loop on this, the LabVIEW 2013 f2 Patch is released on the web and will be going out through NI Update Service in the near future. One of the fixes it includes is for this specific installer builder CAR 429282. The details for the patch are located here and the 32-bit download is located here

 

Thanks

[LogMAN]

Thanks JeffP for the update. I've installed the patch, but unfortunately, this does not solve the issue. I still get <Error generating preview> in the installer dialog.

[JeffP]

Hi LogMAN,

 

I looked into this more and found a case where the patch did not fix the issue. I have tested with your specific case against our new fix, and I believe it should now be fixed. If you take the attached VI and replace the file at LabVIEW 2013vi.libAppBuilderEngineAB_Engine_Update_Source_from_Linker.vi with it, you should be able to build.

 

Please let me know if that doesn't work.

 

Thanks

 

 

AB_Engine_Update_Source_from_Linker.vi

[LogMAN]

Hi LogMAN,

 

I looked into this more and found a case where the patch did not fix the issue. I have tested with your specific case against our new fix, and I believe it should now be fixed. If you take the attached VI and replace the file at LabVIEW 2013vi.libAppBuilderEngineAB_Engine_Update_Source_from_Linker.vi with it, you should be able to build.

 

Please let me know if that doesn't work.

 

Thanks

 

Great, thanks!

 

I'll try as soon as I'm back in the office the week after next week. You'll get an update then.

[LogMAN]

JeffP I've tested your file and it works just great! I can now finally see my precious preview and build the installer!

 

Thanks

[JeffP]

Great to hear! The fix in that file will be included in the next f patch for 2013 (when/if that occurs), it will also be included in LabVIEW 2013 SP1 when that gets released. After that time, it will no longer be necessary to manually replace that file.

 

Thanks

[hooovahh]

Just ran into this one personally.  Not sure what the offending VI is but replacing the one in the vi.lib with the one you posted fixed it.  Can't wait until SP1.