Pre-build Action VI causing crash during source distribution build

[bodypillow]

Hi All,

Using LabView 17.0f2 (64b).  Trying to build a source distribution with a Pre-build Action VI that checks some of the properties of the project and the source distribution before actually proceeding with the build.

I have verified throughput by introducing a dummy pre-build action that does either nothing, or introduces an error, both of which work as expected.  However, when I do what I am actually trying to do, LabView crashes almost immediately with no popup error.  When opening LabView the next time, I don't get any unusual windows, just the usual splash screen, except for the first time it happened.  I didn't screenshot the window that opened but I believe I have the corresponding failure log file which I snipped below.

I have traced the cause of the crash down to using the Project.Open method.  Is this expected?  Is there some workaround I can use to obtain the project reference to do the rest of my project checking without using this method?

Thanks,

[Bob_Schor · Accepted solution]

I'm unsure if this is at all related to the problem you are having, but I've filed (and had rejected) a plea that "Pre-Build Actions" be done before the Build process starts (seems logical, doesn't it?).  Turns out that the Build starts, some aspects of the Build Spec are saved in a cache, then the Pre-Build action is acted upon.

I've since gone to using "programmatic Builds", using the VIs in the Application Builder sub-Palette of the Application Control Palette.  You look up the Build Spec you want, then pass it to the Build VI, after you've done whatever "Pre-Build" actions you want.  You need to write a tiny bit more code, but you know you've done whatever you want to do, and then you Build.

Bob Schor

[bodypillow]

I think I actually came across your feature request thread when I was searching on my issue.

Thanks for the input.  Not too sure what to make of it, but if it turns out to be inherently causing the crashing, one workaround I have thought of would be to move the checks to the post-build operation instead.  Instead of preventing the build from happening, it would basically delete or revert the deployed build if it saw that the build was done with incorrect settings.  Would not be as clean as how I envisioned this working, but would kind of accomplish the same thing with a little more delay for the user before finding out they screwed up.

But anytime I get hard crashes without any kind of indications before or after, I get a little nervous, hence this post...