Phidgets Forums

Did you get to the bottom of this?

I also package Phidget22.dlls manually and always have problems if there is Phidgets Control Panel installed or when upgrading my own software so your last post on potential dependency on Phidgets CP is interesting.

It feels as if Phidget APIs have preference to link dynamically to either a) whatever is installed with the Phidget control panel or, failing this and in case of upgrading the software, b) whatever was installed with previous version of the software (this could be the set-up routine not detecting change in phidget22.dll files that are being upgraded). I basically then get mismatch of dll versioning errors.

My workaround is not to have Phidgets CP installed and to uninstall software before upgrade rather than do normal upgrade. I use simple VS Installer Projects setup.

The .NET library tries to load the C library phidget22.dll from a dll/ directory in the same folder as the .NET library, according to the arch - ie dll/x64/phidget22.dll for 64-bit, etc. Failing that, it looks in the current AppDomain directory for the dll folder. After that it uses standard system paths to find the dll - which would give you a dll in the same folder as the .NET assembly first, followed by a dll in C:\Windows\System32 or other system paths.

-Patrick

Hi,

I looked into this. It seems that with .NET Core 3.1 when you publish, it will embed the native libraries by default, but starting in .NET 5.0 it does not - so even when you build a self-contained single-file app, you end up with all the native dlls alongside it.
This doesn't work - because the Phidget22.NET.dll has been embedded in the .exe, but the dll folder has not. Even though the dll folder is in the same directory as the .exe, the embedded Phidget22.NET.dll does not find it. I'll need to look at adding some additional search paths.

One option is to move the dll for your specified architecture alongside the .exe - ie move dll/x86/phidget22.dll to the same folder as the .exe, and then it's loaded as expected.

The other option is to include native libraries in the published .exe in .NET 6.0. You can set the IncludeNativeLibrariesForSelfExtract flag to true, and the native libraries are embedded - but this does not work as expected for some reason - I'll need to look into it.

To get this working, you need to enable the .NET Core 3.1 behaviour, which is to extract ALL the files before running (in the background) by using the IncludeAllContentForSelfExtract flag:
This produces the truly self-contained .exe which embeds the .NET and C phidget22 dlls.

-Patrick

Hi,

As a further update, I've made some changes to how the library searches for libraries in the latest release - 1.10.20220622

The IncludeNativeLibrariesForSelfExtract setting now works as expected:
The default setting where native libraries are not embedded also works properly now.

-Patrick