PluginSDK.dll Needs a Dedicated Directory

[shill]

If anyone has another suggestion or sees a flaw in my logic, please let me know...

Given:

• PluginSDK.dll should only be provided by the local HS system
• The PluginSDK.dll file is in the bin\homeseer directory
• HS4-based plugins require PluginSDK.dll
• In order to find it, a probing path that includes "bin\homeseer" is required in HS4-based plugin app.config files.

The result is that if there are any other DLLs (like SQLite!) that HS uses that a plugin developer also uses, there is a potential conflict in versions.

If instead the PluginSDK.dll file was in the "bin\homeseer\references" directory (or something like that), we could be more surgical about the DLLs we inherit.

Am I missing something? Is there a better way I can handle this?

[Michael McSharry]

My understanding is that the probing path is listed in order of use so if plugin path is listed before homeseer path then the SQLite version will be found if the plugin path and ignore the one in the homeseer path

Example

<probing privatePath="bin/mcsShelly;bin/homeseer" />

[tenholde]

I do not understand this issue. My understanding, and experience, is the HS4 loads PluginSDK.dll at startup and hence is automatically available for your plugin execution?

[shill]

My understanding is that the probing path is listed in order of use so if plugin path is listed before homeseer path then the SQLite version will be found if the plugin path and ignore the one in the homeseer path

Example

<probing privatePath="bin/mcsShelly;bin/homeseer" />

That is how it's supposed to work and how I have mine set up. But the while doing final tests for my Device History plugin on HS4 on my Linux VM, I was getting a DLLNotFound exception because of the interop DLL. The version of SQLite I was using was more current than HS's version, but as soon as I stopped shipping my own and just relied on it finding it in the bin/homeseer directory, the problems disappeared. Interestingly I didn't have that issue on Windows...

I do not understand this issue. My understanding, and experience, is the HS4 loads PluginSDK.dll at startup and hence is automatically available for your plugin execution?

That is not quite accurate. It is loaded by your plugin as a dependency, just like anything else, based on finding it in the probing path. So you've got to include it if you don't want a DLLNotFound exception for the PluginSDK.dll.

[CarmosKarrvx]

Your suggestion of moving PluginSDK.dll to a separate directory is a good solution to avoid potential conflicts with other DLLs used by HomeSeer. This would allow for a more precise control over which DLLs are inherited by the plugins. Another way to handle this is to use a different probing path for the HS4-based plugin app.config files that specifically excludes the directories containing conflicting DLLs. This could also prevent any version conflicts from occurring. Ultimately, the best solution will depend on the specific circumstances of your plugin development and the DLLs being used by HomeSeer.

[shill]

Your suggestion of moving PluginSDK.dll to a separate directory is a good solution to avoid potential conflicts with other DLLs used by HomeSeer. This would allow for a more precise control over which DLLs are inherited by the plugins. Another way to handle this is to use a different probing path for the HS4-based plugin app.config files that specifically excludes the directories containing conflicting DLLs. This could also prevent any version conflicts from occurring. Ultimately, the best solution will depend on the specific circumstances of your plugin development and the DLLs being used by HomeSeer.

The problem isn't the actual dependent .NET DLLs. It's that the Interop.dll (specifically for sqlite) that apparently doesn't follow the rules of probing paths. And if this problem exists, what other issues might? There's no reason to NOT have it in a dedicated directory, and it would solve this problem for those who use SQLLite in their plugins or for any other similar situations now or in the future. It just makes sense to not invite trouble by having plugin authors point to a directory full of DLLs they don't want.

[dcorsus]

Just weighing in as I had similar struggles at the beginning of HS4. I do put my own (SqLite) DLLs in my own directory AND the .config file points the probing path FIRST to that subdirectory then to the homeseer/bin directory (<probing privatePath="html/Sonos4/bin;bin/homeseer"/>),so it really doesn't matter what HS does. However, my challenge was that the System.Data.SQLite.dll was different for Windows as it is for Linux, so I have both in my install package AND the PI at startup will pick (rename) the correct .dll for the respective OS. I am pretty sure the interop.dll DOES follows the probing path, unless this somehow changed in the last few years, it has worked for me my Sonos4 PI for many years.
Hope this helps

[shill]

Maybe it was a Windows vs. Linux thing, then.

[dcorsus]

Maybe it was a Windows vs. Linux thing, then.

Could be, attached is my bin folder as part of the installer and at startup the PI will rename the Linux/WindowsSystem.Data.SQLite.dll and drop the Linux of Windows prefix from the filename, based on the OS , I'm running under.

[Michael McSharry]

However, my challenge was that the System.Data.SQLite.dll was different for Windows as it is for Linux,

I tried to use System.Data.SQLite.dll in the past and had problems. Likely due to Linux/Window. I was not aware there were two version with the same name. What I have done is use mono.data.sqllite.dll that works under both OS's. I do not know what I may be loosing by using this, but it works for everything I need it to do.

[shill]

For now I'm just avoiding sending it at all and just trying on the one HS provided since I know it works.

[dcorsus]

For now I'm just avoiding sending it at all and just trying on the one HS provided since I know it works.

It has been a while, but pretty sure that the ones I use were from HS, that's how I noticed they had another version for Linux as for Windows