Continuous Integration
Broken build from Jenkins
Not sure where to start debugging this one. An executable build spec runs + builds a functioning application on my dev PC and other developers on the team. However, when the same project is built from Jenkins, we're left with an application that has a broken top-level VI and throws this error when clicking the run arrow.
I've looked through this KB:
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P8fXSAS&l=en-US
- The versions of .NET on my dev machine match what's on the build machine. This doesn't really seem relevant, because the application is broken on the build machine, too.
- NI/Third party drivers - same story, the build is broken on the build machine, so it's not a driver mismatch situation.
- Haven't tried a mass compile yet, hoping to avoid that... Too many circular dependencies in the project, mass compile has about a 50% chance of hanging.
- The exe is built as debuggable, but it doesn't run... Am I reading these steps wrong?
- No Xcontrols in the project
- Not getting error 1502
At first I thought it was related to licensing, so I gave the PC a disconnected license file, but that didn't change anything, either.
Any thoughts?
This is a bit tricky to debug from the information available, but as a blind guess, are you using any statically linked PPLs that are excluded from the executable (which is a reasonable choice, but I think might lead to a valid source configuration/setup producing an invalid output/executable if the PPLs don't exist at the expected paths).
If that isn't the case, can you describe what you are doing in your executable at all, in case someone knows of particular issues with some component/area of code?
I guess you have .NET code from the description you gave.
Thanks for the suggestions - I'm investigating the SYSTEM vs. normal user now. Pretty sure we have it set up to run as the person who manages all this, but it's worth double checking.
Edit: Just double-checked, it is running as a user and not SYSTEM, and that user is an admin on the PC.
are you using any statically linked PPLs that are excluded from the executable?
Nope, all dependencies are included in the executable itself. There are classes that are dynamically called, but those are included. And again - the same project builds + runs on my dev PC and my team's dev PCs. So I'm thinking that the issue is more on the PC configuration (drivers, SW, Jenkins configuration, licensing, permissions, etc.) than it is with the LabVIEW project itself.
can you describe what you are doing in your executable at all, in case someone knows of particular issues with some component/area of code?
I can give it a shot. The code is a take on an MVC architecture that's built on the SMO framework and takes some cues from Actor Framework. There is a main controller SMO that maintains a data structure that contains the state and configuration of the application, and is responsible for maintaining the lifecycle of Views. The Views are also SMOs and communicate to the controller by sending messages (a la actor messages). Some components in the framework use a lot of malleable VIs and the whole thing is OO.
The overall application is a test executive application that's modelled around TestStand but has a similar UX to Office applications. So there are custom test steps that communicate with IMAQ devices, DAQmx devices, and some that just work over TCP. There is one DLL that we call which uses .NET (this was before NI added native TLS support, so I wrote some .NET code that sits between our device under test (TLS only) and LabVIEW). I mentioned the .NET version stuff because that's what the KB was pointing to first. I have no reason to suspect that it has anything to do with that assembly at all, just following the troubleshooting instructions.
