Using external library in Ctrl Extension

[weirdal]

Hi everyone

I have created a new ctrl extension as decsribed in the help document.

If I only build the empty project and copy the result to the WinCC OA project's bin folder, everything is being loaded fine.

As soon as I do have references to an external library, the following error message occurs on GEDI start:
WCCOAui (10), 2020.08.06 13:32:59.724, SYS, WARNING, 133, Could not load shared library C:\<path_to_project>\bin\CtrlExt.dll, The specified module could not be found.
WCCOAui (10), 2020.08.06 13:32:59.740, IMPL, FATAL, 54, Unexpected state, The Ctrl Extension C:\<path_to_project>\bin\CtrlExt.dll is not compatible with the current library version 316000 of WinCC OA.
It might be from version <= 3.6, or a needed external library could not be loaded. (See also previous error message)

I have referenced the external .lib file in the c++ project's properties.
The external .dll file is being copied to the output directory on build time.
I do copy both the resulting dll "CtrlExt.dll" as well as the external dll "External.dll" into the WinCC OA project's bin folder.
Still, the message mentioned above appears.

What am I missing out on?

[weirdal]

It works when I put the "External.dll" into the Windows System32 folder.
Is there any way I could tell WinCC OA to look for dependant libraries in the project's bin folder?

[gschijndel]

Windows searches for external libraries in the directories of the PATH environment variable. On windows it might be possible to change it from the running process itself.

With the DesktopUI the external library must be downloaded before it can be used.

[weirdal]

Thank you for the advice, I managed to do it by including the external lib into the dll.

However, in the meantime we have decided to check out another external framework and I am having severe problems in using that one, too.

When I include the externals in a default console project in VS2015, everything works fine with it. But when integrating it into a WinCC OA created Control-Extension project, it seems that some fundamental Windows related things are missing.

We are using Aspose.Cells for C++ libraries for interaction with Excel files (trial version downloadable at https://downloads.aspose.com/cells/cpp). It has dependencies to the boost library and also some unicode libraries.

As soon as the Aspose.Cells.h is included in the CtrlExtension project this results in numerous Windows build errors, related to Windows files comdef.h and comutil.h (from the Visual Studio 2015 include folders).

It seems that the CtrlExtension project in VS2015, that is created by script, is missing some basic Windows includes, which makes Windows think it is of a version lower than Windows NT and thus does not initialize constants required by dependencies of the external framework.

I'll attach my CtrlExtension test project. Thanks for any advice.

Project

[gschijndel]

We are using Aspose.Cells for C++ libraries for interaction with Excel files

For interaction with Excel you could also use a COM object, see the 'createComObject' function for an example.

[weirdal]

We are using Aspose.Cells for C++ libraries for interaction with Excel files

For interaction with Excel you could also use a COM object, see the 'createComObject' function for an example.

Unfortunately, the goal of the project is to get rid of the antique COM mess. So that is not an option.

[kilianvp]

I have had this problem before. The easiest way is to first create a libary in which only the desired function is contained. Only normal c++ types and functions may be used in the header file. This way you can avoid the conflicts. That' s what the ETM does with the C++ api. Otherwise you would probably have to install the QT development environment.

[weirdal]

Thank you, Kilian. I am considering to try this approach if I cannot find a better solution. Sorry for the late reply, as I have been on holiday for the past week.

Still waiting for a reply from ETM officials and also considering to create an official support request for the issue.

[weirdal]

@Kilian:
I have ultimately used your approach and it is working as described, many thanks for your input.

[kilianvp]

you are welcome! i am glad that it worked out in the end.