08-16-2017 07:31 AM - edited 08-16-2017 07:34 AM
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
08-16-2017 08:40 AM
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.
08-16-2017 09:00 AM
What happens if you put the DLL in the same directory as the EXE? This sounds like a bad path problem.
08-16-2017 09:10 AM - edited 08-16-2017 09:18 AM
Thanks,
Yes, sorry I didn't mention that I also tried that trick & also in c:\windows\system32, but it didn't fix it.
08-16-2017 03:01 PM - edited 08-16-2017 03:08 PM
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).
08-18-2017 04:11 AM
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?
08-20-2017 02:35 PM
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.
08-21-2017 04:07 AM
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..
08-22-2017 03:38 PM
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.
08-22-2017 03:41 PM
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