Search the Community

I have a large project with many libraries which I am trying to release as a Source Distribution. I am regularly releasing standalone executables of that project without a hitch. However, the source distribution, once I open the top level VI in a copy of the project I place in the source distribution folder, after updating all paths to the new destination, ends up with many broken VIs. Examining the source of the problem, it appears that it is due to many (if not all) VIMs in my project being replaced by VIs with made-up names (random series of characters.vi), and the Assert Type VIMs in those VIs being themselves replaced by similarly randomly named VIs, and broken. I recall having read threads about some sort of incompatibility between VIMs and libraries, but since I did not have any problems with them during development (or application release), I am kind of at a loss as to what to do next... Is there some literature I can read on the dos and don'ts of Source Distribution release and VIMs + libraries? LabVIEW 2021 SP1 64 bits on Windows 10.

Hi all, I wrote some code that uses functionalities from lvanlys.dll, so it appears as dependant item in project explorer just like other dlls that I'm linking to (e.g. nivision.dll). When I want to distribute my code as lvlib, lvanlys.dll is copied to destination directory (and worse it becomes part of the lvlib) what causes future conflicts in a project where I use created library. No other dlls are acting like this, only lvanlys.dll. What is the difference between them? How i can avoid of copying this file? Best regards, Zyga

Hello everyone, I've got a situation with source distributions: I want to export the sources of a project, but some of the VIs should not include their block diagrams. (But they do ) This is what I tried: Create a new Source Distribution and under Source Files add all top-level VIs to Always Included. Next in the Source File Settings select certain folders and check the 'Remove block diagram' option (under Additional Exclusions the checkbox for 'Remove compiled code' must not be checked). When I build the distribution and open one of the VIs, which are marked as to remove the block diagram btw, it still has it! I already found out that this is related to all my VIs having their compiled code separated (to keep source control clean, you know...). So in order to archive what I want, I would have to disable that option, let all VIs recompile, build the distribution, enable it again, and let all VIs recompile again to keep my commits clean... What am I doing wrong here? Does anybody know a cleaner way to do this? I'm still stuck with LV2011 btw Thanks for the support. LogMAN

Shortly: We desperately need a good hint on principles describing how an Application (EXE) build interacts with Source Distribution build(s). Descriptions found in ni.com and generally in Internet mostly advise “use Source Distribution” not saying “why”. It works perfectly with simple test projects but is not sufficient for our real needs. Please advice where the general principles can be read. Details: There is a framework code (GOOP4 that means that all problems should be the same with build-in LVOOP). The framework dynamically invokes VIs. The dynamically invoked code also has OOP architecture. A perfect architecture would be creating the framework EXE and keep the dynamically invoked code as loose VIs in HD. However, it does not work. The framework EXE claims that the VIs are broken (while they are not). The common advice is deploying the VIs as a Source Distribution. However, this does not work too. If controlled with a property node “Execution state”, such a VI does not show the result “Bad” but an attempt to start it results in an error. I guess that the problem could be in the fact that some classes are used both the framework (the EXE file) and in the Source Distribution. However, I have no idea how these two builds interact with each other deciding which copy should be used. Unfortunately, error numbers that are shown are poorly described. So far we could guess only that the problem is in finding some sub-VIs. Thank you for reading to the end