App Builder in LV8 not responding (build dll only)

[vituning]

I am working in Lv 8.01. I have a project that has many build specifications, among them .exe and .dll builds. I have built all the exes and dlls in the past. I installed LV 8.20 (but am still working in 8.01), and now when I right-click on any .dll build spec and choose "build" I get the following error:

Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:

Error 1031 occurred at Open VI Reference in ABAPI Dist Build DLL Stub.vi->ABAPI Build Shared Lib With Old Proto.vi->DBEP_Invoke_Build_Engine.vi->DBUIP_Build_Invoke.vi->DBUIP_Build_Invoke.vi.ProxyCaller

Also, when I choose "Properties" for any of the .dll build specs, I see the hourglass, then nothing happens. The .exe builds work as expected.

I have repaired 8.01, and 8.2 and mass compiled my 8.01 vi.lib. I had this problem before and uninstalling 8.20 then repairing 8.01 fixed the problem.

Any ideas, or is this an known issue?

Thanks.

[MattP]

Hello,

I have 8.0.1 and 8.20 installed on my test machine as well, though I can't say I've ever seen this behavior.  Does it do this only for DLL builds contained in this project, and not for any new projects you create?  Does the behavior manifest itself as well if you attempt to create a new DLL Build Spec in this project?

The error implies that the VI its attempting to link into the DLL has a different connector pane than it is expecting, which strongly implies a shared VI is getting updated by the 8.20 installer.  Are you making calls to any special drivers or toolkits in this application, or perhaps using the DSC Module?

If the code is of a reasonable size to post, I'd be interested to take a look at it on my test system as well - it may be a little tricky to narrow down the problem without source that can reproduce the error.  If you can let me know the answers to the above, I'll dig into it and see what could be causing this for you.

[vituning]

Matt, Thanks for the response.

I tried simplifying my problem by creating a new project in 8.01 with a very simple top-level VI that doens't call any subvis. When I try to create a dll build specification, I see the following error:

"There was an error in invoking the build rule editor. Please check the corresponding provider directory to see if any VIs are broken."

and then a dll build spec with an empty name is created (see attachment). It seems like I need to recompile the app builder vis maybe? I have recompiled my entire LabVIEW 8 directory, are these VIs somewhere else? I do not see the error when creating an .exe build spec.

[vituning]

Matt -

I opened every VI in the AppBuilder folder and found the following VI is broken:

C:\Program Files\National Instruments\LabVIEW 8.0\vi.lib\AppBuilder\ABAPI Build Shared Lib With Old Proto2.vi

Seem to me to be a fairly likely candidate to me. I'll try copying this from another one of my machines (that works) and see what happens. It's password-protected, so I can't see where the error is. It shows up as a wire type conflict in the error list.

[vituning]

Last update -

Have an AppBuilder directory with no broken VIs now, but I get the same error. Exe, installer and zip file build specs all work as expected.

Any help would be apprecitated. Thanks.

[ASharma]

I had the same problem building an EXE.  I've done this a ton of times with LabVIEW 8.0, with the same project.  Any ideas?!?

[vituning]

2and4 - I never figured out how to get this to work. Anytime I want to build a dll in LV8.01, I now use a co-worker's machine.

Good luck, and post here if you find the answer!

[ASharma]

VITuning, I actually had the problem with LV 8.2.  Very strange.  Thanks for your help though, and good luck.

[Joe_Gerhardstein]

Bump.

Same problem with 8.0.1.  Have 8.2 and 8.5 installed also.  Can build 8.2 applications okay.

[Joe_Gerhardstein]

Figured part of it out.  I use Subversion for version control.  One of the odd things about subversion is that it stores copies of the previous "HEAD" revision in a hidden directory in each folder of the project tree.  Sometimes VIs within a project can get cross-linked into one of these hidden directories.  Deleting these ".svn" folders out of the directories appears to have solved the problem.