Executable Error Messages - Not Really Helpful

[jgcode]

<gripe>

Sweet! - Just build an application then I get these two messages when I run it, then.... ...nothing.

</gripe>

[PaulL]

<gripe>

Sweet! - Just build an application then I get these two messages when I run it, then.... ...nothing.

</gripe>

I saw the same thing a couple days ago. I'm not sure what the cause was. Here are some of the details.

My colleague had installed a demo version of LabVIEW 2009 on it. I wanted to install a version 2009 executable on that some computer. So we uninstalled LabVIEW (but not quite all things NI because there was an executable installed that we didn't want to remove). Then we attempted to install the LabVIEW 2009 RTE and the 2009 DSC RTE. The former noted that some newer components were installed (so?) and then canceled the install. The latter install succeeded. If I tried to run the executable I saw the same unsupported languages messages. (We installed a 2010 version successfully on that computer.)

Does this sound similar to what you saw? What did you do to resolve the issue, if you were able to resolve it?

[jgcode]

Does this sound similar to what you saw? What did you do to resolve the issue, if you were able to resolve it?

Thanks Paul

It was DSC related and I was able to resolve it simply by selecting the Enhanced checkbox in the build spec the rebuilding.

I was more having a whine about broke builds and error messaging - I think it could have been handled better and I commented on this in another thread:

Unfortunately its not related (the last one was DSC-related) - I was more complaining about the lack of error messaging.

(Why does not it just say you need to include Enhanced DSC Support?, or automatically do it for me in the build, or warn me at build time?)

There is info on ni.com here about the how the different Run Times are handled if anyone is interested.

[PaulL]

It was DSC related and I was able to resolve it simply by selecting the Enhanced checkbox in the build spec the rebuilding.

Hmm... that doesn't apply in our case. We are using DSC but not the functionality that requires that checkbox to be true.

[jgcode]

Hmm... that doesn't apply in our case. We are using DSC but not the functionality that requires that checkbox to be true.

I thought I wasn't, but will have to look closely at the code and cross-check the KB.

But this did definitely fix that issue.

[jgcode]

On a side note anyone seen things like this before:

I have isolated my application where if I disable this VI it doesn't break, if I enable this VI it breaks (keeping in mind I have a whole bunch of other stuff disabled too).

The application loads a splash screen show me all the VIs loading too (which is not what ever want!)

Building the components by themselves in this VI creates an executable that is not broken so I am unsure why toggling between disable/enable would be an issue.

I am wondering if Error 6 - path length error, exceeds 255 character, would cause this?

Wondering whether it is happening but the report is not telling me?

I am building in C:\a tho, as close as I can get to the root.

Still, scratching my head over this one.

[jgcode]

Here is a cool build message:

[Cat]

Here is a cool build message:

Ooo. Can't wait to get that one when I'm 400' under the ocean...

[mje]

Here is a cool build message:

I've seen that "error" many times on 2009. Building applications became the bane of my existence for a while when that error would just creep up and not go away. I never sorted it out, just kept jockeying computers and IDE reinstalls until it worked. It was absolutely infuriating. When I finally got things to work, my installer package had ballooned up in size 2 or 3 times its original size, but I just let it be. Wasn't going to poke that sleeping beast at all, at least I had some kind of deliverable...

Application/Installer building in LV is still a rather arcane bit of voodoo in my opinion. They really need to spend more time developing the reliability of that tool, it is my least favorite part of having to deal with LV.

[jgcode]

I've seen that "error" many times on 2009. Building applications became the bane of my existence for a while when that error would just creep up and not go away. I never sorted it out, just kept jockeying computers and IDE reinstalls until it worked. It was absolutely infuriating. When I finally got things to work, my installer package had ballooned up in size 2 or 3 times its original size, but I just let it be. Wasn't going to poke that sleeping beast at all, at least I had some kind of deliverable...

Application/Installer building in LV is still a rather arcane bit of voodoo in my opinion. They really need to spend more time developing the reliability of that tool, it is my least favorite part of having to deal with LV.

At least I know I am not alone

This one is killing me. 2 days and I *think* I may have narrowed down a class that seems to be corrupting the build at the close of business today.

Still not sure, back on the grind tomorrow... hopefully have it sorted soon?

Branching out into the third day - haven't had a build issue take this long (last time was 2 days).

Serves me right I guess, I wasn't incrementally building on this project either (for what ever excuse reason)

Would not want to be 400 deep with this one

[mje]

Good idea on the incremental builds. I'll have to start doing that as part of my tests.

The odd thing was that in my case, the error crept up from a source code revision tag which had been stable for months (no code changes had been made). I had someone ask for an old executable I made, so I did an export, built it and boom, error. The same source had literally been used a dozen times earlier to build from (there were no user.lib files, I manage dependencies within scc and they're similarly set to a stable tag). Took me the better half of a week to get this person what he had asked for.

[jgcode]

Good idea on the incremental builds. I'll have to start doing that as part of my tests.

The odd thing was that in my case, the error crept up from a source code revision tag which had been stable for months (no code changes had been made). I had someone ask for an old executable I made, so I did an export, built it and boom, error. The same source had literally been used a dozen times earlier to build from (there were no user.lib files, I manage dependencies within scc and they're similarly set to a stable tag). Took me the better half of a week to get this person what he had asked for.

Me too (sort of) the corrupt class (if it is the issue) inherits from a reusable component which I think may be the actual issue.

It did build previously ages ago, so I have no idea why its doing all this now.

The only reason I caught it is that I did a build on an integration VI as the Main VI in the build, and the Front Panel shows Class inputs as "Question Marks".

Need to investigate further tho.

[Aristos Queue]

This whole thread should be posted on ni.com so some AEs can dig into it and file CARs as needed. I frequently file CARs for threads I see on LAVA, but a lot of what you're discussing here is beyond my knowledge to write up.

[jgcode]

This whole thread should be posted on ni.com so some AEs can dig into it and file CARs as needed. I frequently file CARs for threads I see on LAVA, but a lot of what you're discussing here is beyond my knowledge to write up.

Done!

This topic is continued on ni.com

Turns out, most of it is because of the Enhanced DSC Run Time environment.

[Daklu]

Here is a cool build message:

Great, I just encountered this error too.

I guess I'll just call them up and not say anything....

[asbo]

I guess I'll just call them up and not say anything....

[jgcode]

Great, I just encountered this error too.

I guess I'll just call them up and not say anything....

Just breathe heavy down the phone line... lol