LabVIEW
What setting to set to stop .NET dll being copied to build folder
Solved!
To reference the DLL by path (i.e. a specific location) set the Call Library Function Node to reference a path from the block diagram (in the configuration) then wire an appropriate path.
You can use a Conditional Disable Structure to identify if the VI is running in the development environment or the runtime environment and change the path based on that.
Another idea is to check the VI's path and determine if it is in a PPL.
Since the library no longer appears in dependencies if it is not statically referenced, then it won't copy. If you want to copy it (as I have above) you can add it to the dependencies and use the Build Specifications to place it in a specific directory (via the Destinations and Source Files tabs).
Edit: Above I'm using the CDS to change the library name based on the target type - if you have specific patterns, you can avoid this with the use of some wildcards (which in the example above might be possible, but like I mentioned, I changed them when I uploaded the snippet). See the Configuring the CLF Node page for more details.
I don't think that applies to .NET dlls, Christian.
IIRC by default, ,net dlls don't get copied to executables. Unless you add the .dll to a class.
If you added the dll to the class, maybe not doing that will help. I'm not sure how that works with packet libraries. I've been able to avoid them so far.
Search LabVIEW like a graph!
wiebe@CARYA wrote:
I don't think that applies to .NET dlls, Christian.
IIRC by default, ,net dlls don't get copied to executables. Unless you add the .dll to a class.
If you added the dll to the class, maybe not doing that will help. I'm not sure how that works with packet libraries. I've been able to avoid them so far.
Oops. I should learn to read. Missed the .NET.
Sorry Mr Bond...
You should follow Weibe's guidance.
I haven't tried packaging .NET DLLs, either with PPLs/executables or as installable source code (e.g. via VIPM, Source Distribution, etc), so have no useful knowledge!
I tried running some quick tests to check this, but I guess I need a non-system DLL to make any real guesses. Using System.Timers added a "System" object to my Dependencies, but dragging it into the project didn't allow me to include it in the build.
The built PPL functioned the same as the dev environment, without any additional files being copied.
If you have an example/simplified project, I'm happy to try with that instead.
@jamesbond0007 wrote:
What do you mean by adding the .dll to a class? I use a .NET constructor to instantiate the .NET class I want to use.
If that doesn't ring a bell, it's probably not relevant.
If you have a class (or probably a library as well) in LabVIEW (.lvclass, .lvlib) and drop the dll in it (from the LV project explorer) it will be included in the executable, if the class is included. If it isn't it's not included. That goes for an executable, maybe not for packed libraries.
Is there a way to include files in the build spec of the packed library? That might be the way to exclude it, but including it might be default at creating.
wiebe@CARYA wrote:
I don't think that applies to .NET dlls, Christian.
IIRC by default, ,net dlls don't get copied to executables. Unless you add the .dll to a class.
If you added the dll to the class, maybe not doing that will help. I'm not sure how that works with packet libraries. I've been able to avoid them so far.
lvclass and lvlib are mostly internchangable. If you add the .Net DLL explicitly to the lvlib it will always be copied to the lvlibp folder too. lvlibp is simply a lvlib with the diagrams removed (by default) and full compilation applied. And an lvlibp is read only!
wiebe@CARYA wrote:
Is there a way to include files in the build spec of the packed library? That might be the way to exclude it, but including it might be default at creating.
You can specifically include files. You cannot specifically exclude them. If they're dynamically referenced, then they're not included by default. If statically, they are. I suspect that explicitly specifying a constructor for a .NET object creates a static reference (and is therefore included).
But as I posted earlier, I saw something different when I used a system .NET class (I just got the PPL file - no copied dll) so probably to check the behaviour for the OP's case I'd need to find a separate .NET dll to use.
@cbutcher wrote:so probably to check the behavior for the OP's case I'd need to find a separate .NET dll to use.
You can make one:
Very cool...
But now I can test the PPL creation, and my new conclusion is that you cannot avoid copying the DLL file.
If I leave the project from which I build my code open, it remains in memory at the path from which it is built (e.g. C:\Sources\MyNETProject\HelloWorld.dll) and so opening my built lvlibp file causes a conflict as the OP found (expected C:\InstalledFiles\MyNETProject\HelloWorld.dll, found C:\Sources\...)
If I close the source code first, I just load it from the installed/copied version and all is well.
By adding the DLL to my project (before building, so moving out of dependencies) I can at least choose to:
- rename it
- move it somewhere specific
- if I wanted, create a post-build action and delete it, but this might break my PPL... 😕
Perhaps renaming it (HelloWorld.dll -> MyCompany_HelloWorld.dll) and placing it in a desired location (C:\MyCompany\MyNETAssemblies\) you could achieve what you want?
