Open Office Calc DLLs not found. Impossible to run executable

[wiebe@CARYA]

If the VI has a broken error, you might get a more detailed error description if you press the broken run arrow (and post it here).

Have you tried to run the exe as administrator (being an administrator is not the same, you need elevated rights sometimes). A long shot, but cheap so worth a try...

You can compile the exe with debugging on and then connect the dev. env. to it. Not sure if it helps, but maybe (probably not) you'll get another small peace of the puzzle.

Perhaps you can compile a VI with just one of the dlls in it. It doesn't need to do anything, but make sure it's not removed during compilation (dead code removal). Find out if it's just one dll that causes the problem, or which dlls do.

As a last resort, I'd try .NET reflection to find out why it's not working (in a build executable). Lot's of work, no guarantee of any result...

[aRCo]

Hellooo! 

1. About execute as admin -> no luck

2. About clicking on the broken arrow -> BrokenArrow.png

3. About the dependencies -> NativeLibraries.jpg; I cannot find all the dependencies on my PC (the same PC on that the Main.vi runs fine). Missing ones are: the two "api-ms-win-core-..." and "qcall"

4. About the dev.env. -> I think the EXE doesn't run at all, like it stops while checking for the dependencies (this can explain the generic message of point 2)

5. About the simplification -> no luck; even with one only library, it doesn't run

6. About Reflection -> don't have time to make huge investigations

I'm a little bit disappointed and powerless..

Please, any other idea?!?

[wiebe@CARYA]

---

@aRCo wrote:

1. About execute as admin -> no luck

2. About clicking on the broken arrow -> BrokenArrow.png

3. About the dependencies -> NativeLibraries.jpg; I cannot find all the dependencies on my PC (the same PC on that the Main.vi runs fine). Missing ones are: the two "api-ms-win-core-..." and "qcall"

4. About the dev.env. -> I think the EXE doesn't run at all, like it stops while checking for the dependencies (this can explain the generic message of point 2)

5. About the simplification -> no luck; even with one only library, it doesn't run

6. About Reflection -> don't have time to make huge investigations

I'm a little bit disappointed and powerless..

Please, any other idea?!?

---

It seems non of those dependencies are OpenOffice, they all seem native Windows\.NET framework to me. They should be somewhere in the CAG, which is a bit of a mystery on it's own. I think they should be available to all applications.

It's puzzling why the exe can't find those, while the dev.env. can find them.

Definitely do not distribute kernel32.dll (or other system dlls) with the executable!

It seems OO is not official supported in 64 bit applications. Are you using LV 64-bit? It would still be weird that the dev.env. works and the exe doesn't, but it's a thread to follow...

[aRCo]

Definitely do not distribute kernel32.dll (or other system dlls) with the executable!

Thanks for the suggestion and the support more in general. Normally I use to call a VI after building the EXE to delete this DLL in case it is included in the data folder of the application.

LV is 32bits as well as OpenOffice. Windows is 64bits

[wiebe@CARYA]

I used the attached VI in LabVIEW to see if it would give a useful error (it doesn't load in dev.env. for me).

I suggest you try this .NET reflection in the dev.env. as a baseline (no error expected) and in an executable. You can try to drop the VI on the executable, probably no need to compile it! Make the constant a control, so you can reuse it for each dll.

I got an error at first, until I remembered I had to unblock the dll. This is needed if you extract it from a zip. 

Bottom line is you can try to see if it gives a more sensible reason that LabVIEW...

You can use the reflection .net assembly to get more info, like dependencies, methods, properties, parameters, etc.. It's not that much work if you have a clear goal... 

[wiebe@CARYA]

BTW, this thread is pretty much exactly the same problem.

Especially:

---

@Harvster wrote:

--Somthing not obvious is that I have to replace the dlls I already have with the ones that LabVIEW included even though they're identical. Nothing has changed about those dlls. Apparently LabVIEW is doing something to them.  Even though they still seem to be identical.  I'll have to do a binary diff to determine what LabVIEW is changing (A better question is WHY LabVIEW app builder messing with my dlls?!?). 

---

Just another idea (running out of them, btw )...

[aptivo]

Is it possible to register the corresponding dll and load it via the cache? To register use the regasm.exe (https://docs.microsoft.com/de-de/dotnet/framework/tools/regasm-exe-assembly-registration-tool).

[wiebe@CARYA]

---

@aptivo wrote:

Is it possible to register the corresponding dll and load it via the cache? To register use the regasm.exe (https://docs.microsoft.com/de-de/dotnet/framework/tools/regasm-exe-assembly-registration-tool).

---

That registers the .NET assemblies for com clients. Not sure how that would help, but as we're running out of options...

[aRCo]

Thanks guys!

I used the attached VI in LabVIEW

I used it too and had additional information in the form of an error number 1172 (take a look to the attached image ErrorDescription.png). It sounds like a problem about .NET versions and mixed mode.

I start to feel confident about finding the solution.. 

[aRCo · Accepted solution]

Solved!

As told in the LV help (LabVIEWhelp.png) or in this page, a config file have to be crated in the same application folder having the name "<Application name>.exe.config" and containing the following few lines:

<?xml version ="1.0" encoding="utf-8" ?>
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
  <supportedRuntime version="v4.0.30319" />
  <supportedRuntime version="v2.0.50727" />
</startup>
</configuration>

Thanks to everyone for the support and a special mention for wiebe@CARYA: your VI drove definitely the search for the solution