LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

1386 error with Dotnet 2.0 DLL config file doesn't work

I'm calling a 3rd party DotNET 2.0 DLL in Labview 2014.

The DLL is TopCONAPI.DLL here

www.regatron.com/en/products-topcon/software-products/programming-overview/topcon-api

I have confirmed it's coded in .NET 2.0 using ILSPY

The PC has .NET 4.6.1 & 3.5.1 installed, I don't think it will let me install the old 2.0 as well.

 

It works fine in edit mode with a labview.exe.config file with the contents:

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

 

based on advice elsewhere, incl

http://digital.ni.com/public.nsf/allkb/567F6EFFC5669C348625739B003739CD

 

I've built the project as an .exe file but when it gets to the .NET constructor it throws the error '1386, Main.exe, specified dot net class is not available in Labview'.

 

Any suggestions how to get round this? I smy .config syntax missing something ?

Many thanks for any tips, Brian

 

 

0 Kudos
Message 1 of 15
(3,961 Views)

NB, the .exe file is called Main.exe, I have tried co-locating a main.exe.config file containing:

<?xml version ="1.0" encoding="utf-8" ?>
<configuration>
   <startup useLegacyV2RuntimeActivationPolicy="true">
      <requiredRuntime version="v2.0"/>
      </startup>
</configuration>

I also tried it as Main.lvproj.config next to the .lvproj file, but neither worked.

0 Kudos
Message 2 of 15
(3,933 Views)

What happens if you put the DLL in the same directory as the EXE?  This sounds like a bad path problem.

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
0 Kudos
Message 3 of 15
(3,931 Views)

Thanks,

Yes, sorry I didn't mention that I also tried that trick & also in c:\windows\system32, but it didn't fix it.

0 Kudos
Message 4 of 15
(3,925 Views)

You didn't mention LabVIEW bitness so I assume you are running LV 2014 32-bit and are using the x86 versions of the dlls. I downloaded the API and has builds for x86 and x64; you should use the version that matches your LV bitness.

 

.NET Framework 3.5 contains .NET 2.0; so you don't need to worry about installing that. My inspection of the dll itself shows that it is compatible with 3.5. However it also showed that it has dependencies on other dlls; directly to "TcioWrapper.dll" and then indirectly through that to the other named "tcio_x.dll" dlls. All of these should be present in the same folder as your exe (or the data folder that is created when you build); alternatively you could install them to the appropriate system folder that hosts 32-bit libraries (note that its SysWOW64 on Windows x64 that hosts the Windows-on-Windows64 layer for 32-bit applications to run on a 64-bit OS).

 

Dependency on "TcioWrapper.dll"Dependency on "TcioWrapper.dll"

Dependencies on other "tcio_x.dll" Win32 librariesDependencies on other "tcio_x.dll" Win32 libraries

Message 5 of 15
(3,909 Views)

tyk007, thank-you so much for your detailed suggestions 🙂 🙂 

 

Yes, I'm running the x86 Dlls on X32 Labview on W7 X64,

I checked in ILSPy, TopCon API has  Architecture: 32-bit

TCIOWrapper has : Architecture: AnyCPU (64-bit preferred)

ILSpy can't decompile TCIO, TCIO_x.DLL "This file does not contain a managed assembly" which I think is because they're C DLLs which are nearly impossible to decompile so we have to assume they are indeed x86 compatible.

 

So I downloaded the latest version of the DLLs & somehow it fixed the 1386 error and seems to load the main TopConAPI.DLL, and finds but can't load the TCIOWrapper.DLL - it throws a 1172 FileLoadException error

 

I tried putting the DLLs in the main.exe folder, also the\data folder, also in c:\Windows\SysWow64

I gather since Labview 8 we don't have to put the DLLs in the main.VI folder or tools.register them.

 

Mmm, all works fine in edit mode running from the .VI file

I note that in project explorer it has the main TopConAPI.DLL listed in dependencies, but not the other DLLs & no obvious way to add them - it that correct?

Is there anything I might have missed in the Build configuration?

 

0 Kudos
Message 6 of 15
(3,895 Views)

You can always manually add the files and known dependencies to the project (just add an existing file); make sure they are included in the build spec. Then they will end up in the data folder (by default; though you can change this in the configuration). You don't have to just add LabVIEW constructs to a project; you can add any file (including documentation etc.) and if you wanted you could add build folder targets and then specify the locations for the files to go. See here the options for "Destinations" and "Source File Settings" for details.

 

Yes, the TCIO_x.dll are Win32 libs and you can't decompile them - thats why the other assembly is called "Wrapper" inferring it is providing a managed wrapper over lib calls to them. 

 

As far as the FileLoadException goes; you should post the message content. All .NET exceptions that are thrown from the assembly are wrapped into a 1172 coded error, but the message contains the exception content. The other option is to take a look at the Fusion log (https://docs.microsoft.com/en-us/dotnet/framework/tools/fuslogvw-exe-assembly-binding-log-viewer) to see if there is any detail on why the CLR can't load the assembly or its dependencies. There will be an event in the Event Log too but typically this doesn't have enough detail.

Message 7 of 15
(3,873 Views)

tyk007

Thanks again for another helpful and detailed response.

The error content is:

Error 1172 occurred at Constructor Node System.IO.FileLoadException: Could not load file or assembly 'TcioWrapper.DLL' or one of its dependencies. A dynamic link library (DLL) initialization routine failed. (Exception from HRESULT: 0x8007045A)

Possible reason(s):
LabVIEW:  A .NET exception occurred in an external assembly. For information about correcting this error, copy the following exception (in bold), and search the Microsoft Developer Network (MSDN) Web site or the Web for a possible explanation.
System.IO.FileLoadException in SAS_Connect.vi->SAS_static_IV_curve_V2.vi->Main.vi

 
The MSDN page for System.IO.FileLoadException is:
https://msdn.microsoft.com/en-us/library/system.io.fileloadexception(v=vs.110).aspx
it gives some tips, but I think they're mostly more relevant to the coder of the .NET DLL:

1) Make sure that the file is a valid .NET Framework assembly.
2) Check to make sure an assembly or module was not loaded twice with two different evidences.
3) If using the RegisterAssembly or UnregisterAssembly methods, check to make sure the assembly name is not longer than MAX_PATH characters.
4) If loading a satellite assembly, make sure the specified CultureInfo matches the file's CultureInfo.

 

I tried installing visual studio & running fuslogvw, but it's set to logdisabled in the settings & greyed out, one blog suggest enabling it with registry scripts.

 

mmm..

0 Kudos
Message 8 of 15
(3,860 Views)

Perhaps you could post your project or a demo subset thereof (zip the whole folder up); that would allow us (or me) to better debug what is going on.

0 Kudos
Message 9 of 15
(3,847 Views)

As for Fusion logging; Scott's blog (while often full of little titbits) does give a good description for getting it oeprational and usage: https://www.hanselman.com/blog/BackToBasicsUsingFusionLogViewerToDebugObscureLoaderErrors.aspx

Message 10 of 15
(3,846 Views)