Hi,
wondering if it is possible to import a driver to DIS from Cube and have it retain its DLL references?
Hi,
The import protocol functionality in DIS is rather limited: Importing a driver will only import the protocol XML file. After importing the XML file, you can open a QAction which will result in the creation of a temporary solution (which gets created in the %LocalAppData%\Temp\DIS\Solution directory) and QAction projects when you click the edit QAction icon (the QAction projects get created in the %LocalAppData%\Temp\DIS\Qactions directory).
When DIS generates a QAction project this way, it will try to resolve the assemblies mentioned in the dllImport attribute of the QAction tag. It does this by probing the folders mentioned in the DLLs tab of the DIS settings window which lists the DLL import locations.
This list typically contains the following entries:
- C:\Skyline DataMiner\ProtocolScripts\DllImport
- C:\Skyline DataMiner\ProtocolScripts
- C:\Skyline DataMiner\Files
For example, in case you imported a protocol that has a QAction where the dllImport attribute mentions x.dll, it will try to find that assembly in one of the mentioned folders. If the assembly is found, it will add a reference to that assembly in the generated QAction project.
In a scenario where the machine that hosts the DataMiner Agent from which you import the protocol is the same as your development machine the assembly will be found (provided that the folder is listed in the settings window).
Also note that nowadays we encourage to develop a connector as a Visual Studio solution. DIS supports converting a protocol XML file to a solution but there are some limitations regarding the assembly references, especially if the connector makes use of NuGet packages. This is because when creating the solution from a protocol XML file, we do not have all the required information (e.g. which assemblies were part of a (transitive) NuGet package.)
In summary, the import (and conversion) functionality has some restrictions so some manual operations could be required to set the correct assembly/NuGet package references in a solution that is created after importing a protocol XML file and converting it to a solution.
alright sounds good, appreciate the explanation