SQLite DLLs Windows vs Linux - install.txt example ?

[nfrobertson]

I'm trying to make sure I understand what is needed so I can use SQLite in a single plugin supporting both platforms. I am aware you need a PLUGIN.exe.config so you can point your plugins EXE at the right DLL(s). Something like below:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="Bin/YOURPLUGINHERE"/>
    </assemblyBinding>
  </runtime>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
  </startup>
</configuration>

WINDOWS
Appears to need both System.Data.SQLite.dll and SQLite.Interop.dll which you get from your Windows HS3 and at plugin install time copy to the path listed as "probing privatePath" above. The file details page on both of these report version 1.0.87.0 and are from 2/14/2014.


LINUX
Appears to need only System.Data.SQLite.dll You apparently have to get this from the HS3 linux tar.gz file as it's a bit similar in size thus not identical to the one used with windows. This also reports version 1.0.87.0 but is dated 11/13/2014 if you extract it on windows and check it.


I've done a good deal of testing all the combinations of these two DLLs and suffice to say, what I've put above is what I find to work, anything else throws strange errors and won't open the SQLite db3 file.

So it seems we need some install time magic to get the right platform specific DLLs in place from a single plugin distribution. Does someone have a good example install.txt to handle this during plugin installation time? Surely someone already has this working well?


Thanks
Nathan

[CFGuy]

What I ended up doing is to put both dlls in my install file.
One I named Linux_System.Data.SQLite.dll
The windows one is named Windows_System.Data.SQLite.dll.
The install script copies both files to my plugins Bin directory.

Then during the startup of my plugin I use hs.GetOSType to rename the correct dll to System.Data.SQLite.dll and delete the other one.

[Pete]

There is also the WeatherXML files get put in the Bin directory verses the bin directory in the HomeSeer directory in Linux. (upper and lower case bins)

The System.Data.SQLite.dll in the bin directory is the Linux one. When the System.Data.SQLite.dll windows version was installed on linux it was causing an issue with sqlite DB stuff.

IE:

WeatherXML Bin for Linux ===> /HomeSeer/Bin
Rest of plugins stuff for HS3 get put in bin for Linux ==> /HomeSeer/bin

[spud]

A long time ago, I requested a "If Linux" condition in the install script
http://bugzilla.homeseer.com/bugzill...ug.cgi?id=1203

but it never materialized

the common workaround is to build 2 different packages: one for Linux and one for Windows. Then in updater.txt or updater_override.txt, you would have 2 lines for the same plugin, one for Linux, one for Windows.

[rjh]

I don't have a problem adding a conditional, I see it does make things easier. I will require your plugins to only work on the version of HS3 that had the change, so that is a drawback. I will note it for when I am working on that part of the code, no promises as to when it might get in there.

For now, the solution is to just have 2 zip files and let the updater pick the correct one based on the users system.

[nfrobertson]

Thanks for the help understanding this. For now I'll go down the path of two distributions and two lines in the updater file (31=windows, 47=linux). It's also good to have confirmation on the SQLite files needed as that was confusing as well.

Nathan

[beerygaz]

I have different challenge. It seems my plugin requires SQLite.Interop.dll for both Windows and Linux. Given a nuance in mono, I can name the Windows on SQLite.Interop.dll and the mono one libSQlite.Interop.so and get away with it.

However, I run into problems with ARM-based processors as for that, I need a different version of libSQLite.Interop.so

So, how do I ensure I deploy the right version based on Widnows/x86 Linux/ARM Linux ?

[rjh]

The install process only has checks for Windows or Linux, not any processor type. You could try to have the installer install both files into different sub folders. Then when your plugin starts, figure out what processor you are on and then copy the required file to your plugins bin folder. The only issue here is that .NET may look for the DLL when the program starts and then fail because the dependent assembly is missing. But its worth a try.

I have different challenge. It seems my plugin requires SQLite.Interop.dll for both Windows and Linux. Given a nuance in mono, I can name the Windows on SQLite.Interop.dll and the mono one libSQlite.Interop.so and get away with it.

However, I run into problems with ARM-based processors as for that, I need a different version of libSQLite.Interop.so

So, how do I ensure I deploy the right version based on Widnows/x86 Linux/ARM Linux ?