02-22-2022 09:28 AM
I have an application that calls .net dlls which depending on configuration are neither use nor installed in all instances. In cases where a large application needs to be installed to have them, they are not wanted either.
This results in the application searching for the missing dlls and opening broken if the irrelevant third party software is not installed on the station. I need to include the feature because some instances do use it.
I see that there is a type specialization structure which appears to work for broken wires but does not handle missing .net dlls. What are some tricks that I can do to make the executable ignore the missing dlls?
02-22-2022 11:42 AM
I see a few options...
1) Put the .NET code in plugins. For instance, make a empty class that's used by default, and put the child class (with .NET code) in a packed library (ppl). Load it with a factory pattern.
2) Make different executables. Put the (all) .NET code in conditional disabled structures (type specialization structures are of little use here). Add a project variable, and use it in the conditional disabled structure. Optionally, use a pre build step for different executables to automatically set the variable.
02-23-2022 08:24 AM
I'm able to configure Conditional Disable Symbols in the project for running in development mode. How do I assign them to the executable? Are they a line in the ini file, a parameter I can't find in the build specs or another type of method I'm not thinking about?
02-23-2022 08:43 AM
Anything behind a conditional disable structure in a frame that is not enabled at time of compilation of an executable is inevitably and completely stripped from the executable product. The conditional disable symbols can NOT change at runtime, they are a pure edit time feature that will prevent the compiler from even looking at the code contained within frames that are not enabled at compile time. And the Application Builder basically simply collects the compiled code products of all the VIs and puts them in an executable, dll or packet library. So the code is simply not there anymore, nade, njet, futschi.
To have a choice at runtime you need to build your products into their own container (packed libraries are almost ideal for this) based on conditional compile symbols at build time and then select the relevant component dynamically at runtime yourself by loading it into your application. The mentioned plugin architecture is one of the simplest methods to do so, but yes relatively far from just flipping some symbol value somewhere.
02-24-2022 04:18 AM - edited 02-24-2022 04:20 AM
@Steve_Block wrote:
I'm able to configure Conditional Disable Symbols in the project for running in development mode. How do I assign them to the executable? Are they a line in the ini file, a parameter I can't find in the build specs or another type of method I'm not thinking about?
See this idea (and consider adding your kudo): Conditional Disable Symbols settable in Application Builder - NI Community
Follow the link in there:
Solved: Scripting Conditional Disable Symbols (#IfDef) - NI Community
Once you can set the symbol's value from a VI, you can add it as a pre-build action in your build spec.
I agree that a PPL is a better solution, but I still also use symbols to do things that aren't easily\practically put in a module.