Jump to content

Recommended Posts

Thanks to the nice work of drjdpowell I was able to easily connect & work with PostgreSQL. Did have to use the 32bit included dll's though.

Now when I try to install & run it on a Win10 IoT machine the dll's are not found and throwing errors. Sorry no screenshot at the moment.

The 64bit of PostgreSQL is installed on both machines & works.

The exe of course works just fine on the dev machine.

Does anyone have any ideas? I'm at a loss at the moment & need to get this running.

Thanks.

Share this post


Link to post
Share on other sites

I'll have a look when I get a chance.  You might just need to install 32bit postgres, just to get the pq dll from it. 

Share this post


Link to post
Share on other sites

If this is an EXE, see if libpq.dll and other dlls are included with the EXE, in its "data" folder.  This should happen automatically (because the dlls are part of the PQ class), but I've seen this fail before.  If they aren't there try using "Always Include" to include them.  The data folder should look like this:

880985272_2019-07-0310_32_46-TestPQProperties.png.5c045053bf59532f8f04a8773dd653a1.png

Share this post


Link to post
Share on other sites

Correct, the above is exactly the same for the build & works from different directories on the dev machine. It's on the deployed machine it gives errors.

In the Build properties for the exe I've tried to set the destination to a specific path but it didn't help. Perhaps I missed something?

image.png.a02c1101d4a8e779c13c11bd44cb3cbc.png

Share this post


Link to post
Share on other sites

If those DLLs are there then my only idea is that perhaps there is an additional dll that is needed, one installed on your Dev machine but missing on the deployed machine.  What is the exact error message?

Share this post


Link to post
Share on other sites

Try your exe on a regular Windows 10 computer that does NOT have Postgres installed.  This is to tell if it is a missing dll in the build, or something about Windows IoT that is the problem.

Share this post


Link to post
Share on other sites

On a regular Win10 box the exe loads the dll's just fine & then times out as expected without Postgresql installed. So it's looking a lot like a Win IoT issue...

My understanding is that you wrapped 32 bit dll's with a CIN.

Looking at does-windows-iot-support-my-dll

the answer was:

Windows IoT required DLL to be as follows:

  • Compiled using the ARM target
  • Needs to target .NET Core

Those restrictions strictly apply when using UWA you may be able to get away by using a console app but it is not that simple on IoT as everything is sandboxed.

Otherwise the other way to use the DLL on the Pi is to run a nix OS like Raspbian, install the latest MONO and then you can embed DLL's into your projects and it should just run, even if targeted for x86 - Thanks to all the clever stuff mono does.

Edited by FixedWire
typo

Share this post


Link to post
Share on other sites

Ah, so you need to get DLLs compiled for ARM.  I think I just got those DLLs from the postgres install.  If you have postgres on the ARM, look for those DLLs and replace the current versions with them.

Share this post


Link to post
Share on other sites

If Postgres is already running on the Win 10 IoT box, I should be able to link the CINs to the same installation C:\Program Files\PostgreSQL\11\bin. Theoretically.

LabVIEW 64bit hung up when linked to these installed dll's. Hence using the 32 bit dll's supplied & going that route in the first place. It just worked. Note that there also some changes such as libint.dll likely replaced by the libintl-9.dll in the \11\bin directory.

Win 10 IoT Enterprise should be able to run regular programs where as the Core version is limited to UWP apps (understanding this requires ARM compiled code). what-s-difference-between-windows-10-iot-versions

I think Win IoT is mulching things somehow where regular Win 10 accepts the dll's.

Looks like the best approach for right now is to remotely get into the database via the localhost/IP address and run things on a laptop. Your help's been very appreciated!

Share this post


Link to post
Share on other sites

Windows IoT is not a normal Windows installation at all, except the Windows IoT Enterprise version. The others are really just embededded kernels without any real Win32 subsystem. Accordingly many standard Windows DLLs like kernel32.dll, user32.dll and many more are not present there. It is basically a Windows installation with a much smaller embedded kernel that only supports Universal apps from the app store.

Accordingly a normal LabVIEW build application that you created on your dev machine should NOT even be able to be started as they are build for x86 and not ARM and require a fully functioning Win32 subsystem. How do you target your IoT system?

Share this post


Link to post
Share on other sites

Yes, correct Rolf. The target was the enterprise version & that's why it ran in the first place.

Interestingly enough installing the exe on 3 other machines under Win10 resulted in the 2 working & the 3rd not finding the dll just like the Win10 IoT. With a new build it suddenly didn't find the dll on one that did work. With not having time to debug I created an installation and the program worked since even with new builds. On regular Win10 there shouldn't have been an issue...
At this point I'll try and link the latest 64bit Postgres dll's & try that.

Share this post


Link to post
Share on other sites

Well in that case the remark about the DLLs having to be compiled for ARM was really off. That is for Windows IoT installations on targets like the RPi and similar boards which all have an ARM CPU (and accordingly can't run Windows IoT Enterprise either which is a pure x86/x64 install).

It all depends on which C compiler they used to create those DLLs. Until Visual C 2015 or so each Visual C version come with it's own specific C runtime library that had to be installed on every target on which you wanted to run an executable or DLL created with it. While many parts of Windows are compiled with Visual C too and therefore cause the Windows installation to come with the needed C runtime support already installed this can and will vary depending on the Windows version and the amount of extra tools and utilities that you install. Also any extra custom application you install such as LabVIEW also comes of course with the necessary C runtime support that gets installed if not already present on the system, but depending on all this a particular C runtime version may or may not be present on any particular system.

Basically you should never copy DLLs to a target system but install them with the proper installer for them which hopefully takes care about installing the correct C runtime support too.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.