kernel32.dll gets included in support folder

[Serge67]

Hi, 

I had to provide multilanguage support in my application (English and Russian) and I chose Unicode functions for that purpose from this webpage:
https://decibel.ni.com/content/docs/DOC-10153

Calls made to kernel32.dll for string conversion between ASCII and Unicode and that forces application builder to include kernel32.dll into support folder. I seem to be unable to exclude kernel32.dll from being added. Next, application installer will pick up the kernel32.dll. If I try to delete it prior to creating installer, it will detect missing file and will not build. So, letting installer to copy kernel32.dll on a target PC seems strange, but works if both LabVIEW development PC and target PC have same Windows flavors and both 32-bit. The real trouble starts when 32-bit kernel32.dll is copied on 64-bit Windows 7. Then application will crash before it loads. The workaround, of course, is to manually delete 32-bit kernel32.dll that was placed there by installer.

Is there way to tweak application builder so that it will not automatically include a copy of kernel32.dll and let my application to use the one from Windows on target machine?
Is there other library I could use for Unicode in LabVIEW that is not married to kernel32.dll?

I am working with LabVIEW 2011 on Windows7 SP1 32-bit

Thanks,

Serge

[WearWolf]

Hello Serge67,

Would you mind attaching the project files so that we could attempt to replicate the issue?

[rolfk · Accepted solution]

Make sure that any Call Library Node that accesses a kernel32.dll function, only contains the DLL name without any path information. The "Library Name or Path" being a name only tells the application builder to treat the DLL as system preinstalled and not copy it as a private DLL into the application build. This is actually also documented in the Online Help to the Call Library Node.

[Serge67]

Thank you, rolfk! Your suggestion worked for me

[Dr_M]

I have just come across the same problem when building a LabVIEW 2015 application that uses Unicode string display in captions.  I have found that a LabVIEW subVI called "STR_ASCII-Unicode.vi" called by "Open Registry Key.vi" contains a call to the function MultiByteToWideChar in kernel32.dll, but uses the full absolute path to the DLL.  Another function call in the same VI to "getACP" does not.  Editing the function call in this VI and rebuilding the application no longer places a copy of kernel32.dll in the support folder.

[alpony01]

Thank you Thank you...My .exe was crushing on exit because i was writing the full path name