Search the Community

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