Hi Dojo,
Is there a minimum DataMiner version to take into account when consuming NuGets in a Protocol solution?
According to this post: https://community.dataminer.services/nuget-use-in-system-development/
The NuGet DLL should end up in this folder:
C:\Skyline DataMiner\ProtocolScripts\DllImport\slc.lib.common\1.1.4.2\lib\net462\SLC.Lib.Common.dll
Though, I noticed the DLL ended in the ProtocolScripts folder directly. (I used a DMProtocol package generated by the Jenkins pipeline)
Also after copying the DLL manually into the correct folder, the QAction code still didn't compile well.
Therefor I believe this could be a DM version related issue. The setup where I'm trying out this feature is on: 10.0.0.0-9118
I have now reverted using the NuGet, and I'm using the former Generated Class Library code as workaround for now.
Hi Thijs,
The notion of the DllImport subfolder has only been introduced with RN26605 (DataMiner version 10.0.10). With this RN, the ProtocolScripts\DllImport (in addition to the Files and ProtocolScripts) folder is also used as a hint path to search.
Prior to this version, only the Files and ProtocolScripts folder were used as hint paths, meaning that when you have e.g. the following value "slc.lib.common\1.1.4.2\lib\net462\SLC.Lib.Common.dll", it would look right under ProtocolScripts: "C:\Skyline DataMiner\ProtocolScripts\slc.lib.common\1.1.4.2\lib\net462\SLC.Lib.Common.dll", whereas starting from 10.0.10, it would also look under "C:\Skyline DataMiner\ProtocolScripts\DllImport\slc.lib.common\1.1.4.2\lib\net462\SLC.Lib.Common.dll".
Putting the folders under ProtocolScripts instead of ProtocolScripts\DllImport should let DataMiner find the DLLs on the version you are using.
Thanks Pedro! Moving the NuGet DLL folders 1 layer down into the “ProtocolScripts” folder instead of the “ProtocolScripts/DllImport” fixed the compilation errors. Thanks! I’ll also look into upgrading this DataMiner agent to the most recent version. 😉