I would like to use C\C++ generated DLLs in LabView, like this example or this one.
I am wondering if it deploys and runs the code on my target machine (my PXIe) or the DLL runs on the computer which is running LabView.
National instruments, in its using external codes in LabView page 15 under Characteristics of the Two Calling Approaches, mention that,
You compile the source code and link it to form executable code. If you
already have a compiled DLL, this step is not necessary.
LabVIEW calls the executable code when the Call Library Function
Node or CIN executes.
LabVIEW passes input data from the block diagram to the executable
code.
LabVIEW returns data from the executable code to the block diagram.
Which I believe it does not clarify whether or not the DLL runs on the target device, aka real-time.
Moreover, I found this document which was quite confusing since it did not refer to any specific method directly.
Side note: I need to run C/C++ code on PXIe and I need to call it from my LabVIEW code real-time.
I have never done this, so I can only try to give a few hints which might help:
If you want to use a dll, it must run on the target where your LabVIEW application runs: If your application runs on a desktop computer, the dll is accessed on the desktop computer. If your application runs on the PXI, the dll must run on the PXI.
Have a look at this NI website:
If the shared library is C++-based, National Instruments strongly
recommends using the MSVC 2009 or MSVC 2010 compilers.
and
If your DLL works on a Windows machine, it may work in LabVIEW
Real-Time (NI PharLap ETS). However, the code will fail if it calls
functions that are not included in the Real-Time operating system's
subset of Win32.
On this website they also have a tool which checks whether a specific dll will work.
Related
The user's main application is ms-access (with ms-sql server). Ton of code in vba.
One of the main features i have to manifest is controlling my client's voip telephony. My plan is to make a COM DLL that the ms-access can use.
As of now, i've managed to write a C# project (vs2019 .net framework) that handles the voip pbx well, using json, and do all missions necessary, such as invoking calls, sending sms, get calls list, recodings list, get recordings wav files and convert them to mp3. I use Newtopsoft.Json and NAudio.Lame.
BUT it only works as a standalone .net project or exe.
As a COM DLL (class library) - ms-access can handle and use it UNTIL it gets to the part where the code uses ANY external dll's functionality - and it crashes (with newtonsoft) or just not working (with naudio), although the dll's are in the working folder.
I know i have to found a way to make these external dll's to work under the office (32bit) enviroment.
I was trying and guessing many code samples for a couple of days. I tried to follow the Assembly.Load/From/File examples to dynamically load and include the dll's, but i failed to assimilate it in my code or even to understand it enough.
I hope i'll get a solution here.
Thanks :)
Hum, I am able to create a COM object for use with Access. External library code (in my case Newton soft) for serializing data works just fine when that class code is used as a COM object from Access.
You don't mention if the other libraries are managed code, or external win32 .dll? I have however used un-managed .dll’s with a .net COM object, and then have consumed that from MS-access.
The only issue would be in project explorer is to ensure that you have a copy local setting = true for the external referenced .net .dll libraries. (And that is the default, so I am sure you do.
The next issue of course is of course is there any use of configuration files? (app.config) etc.? The reason for this of course that since your application is being launched with msaccess.exe, then the config and settings will be assumed to be in the office install folder, and not the local application. As a result, it not all so practical to move/copy those app.config files to the office folder where msaccess.exe resides. And the config file name will not only have to be in the same folder, but also named.
Msaccess.exe.config.
In place of
YourDotNet.exe.config
Now of course, if you build your project as a .net exec? Well then of course any config settings (application ones, not user) will be placed in this config file, and of course that file will have to be placed in the same folder as the .exe file.
So, one might add a “test” function (any function is a method of that class) to the class that you test/call from VBA to ensure that such settings are being seen and read (if you are using any settings).
Eg:
System.Reflection.Assembly.GetExecutingAssembly().Location + ".config"
So, return that to access and display this result.
The other issue is of course to FORCE your project to x86. I would not use “any” CPU. While this “may” work, since you are using access x32, then I would force compile your .net class to x86 as opposed to “any” CPU. This would also spit out some errors in case some of the external assemble(ies) are compared to a particular bit size and thus x86 settings will result in your class not consuming some of the external .net .dll’s.
Now you “note” that your project works as an .exe, and then “sort of” works as a class and “.dll” registered as a COM.
However, you don’t mention how you are “flipping” this from an .exe to a class, or do you simply have a .net “test” project that you run as an .exe, and it of course has a reference to that class .dll. And you NOT using “COM” for this testing.
If your test.exe program can use that external assembly?
Then I would create a test2 project, but this time around do NOT reference the assembly (as .net), but try using .net CreateObject(). (I think c# has this choice – vb.net certainly does).
So you could try + use a CreateObject() in this .net test sample, and thus test from .net as COM.
So this test .net program (one that has NOT referenced the assembly) would a intermediate test before you jump all the way into ms-access + VBA test code.
However, I would first test/check if an app.config file is being used here, since as noted when you flip to a COM object, and then create a instance of that object in Access/VBA?
Then the config file will NOT be used. You can in .net code force/change the app.config file in that running assembly, and I can’t seem to find my code example that does this. But I am not going to dig too hard until such time we confirm that you are using app.exe.config file here.
Edit
Out of cuirous, I googled naudio. It is managed code. So, that library should work just fine. If that project is compiled as "ANY CPU", you COULD try re-compile as x86, and also re-compile your test program as x86. Then when you create a COM object, then again compile that as x86.
As noted, I do quite a bit of COM stuff for ms-access, and I have without issue used Newtonsoft (for jason serializing/de-serializing) as a COM object that is consumed by ms-access.
And given that naudio is managed code then I don't see why it would be an issue. Any other 3rd party .dll's you using here? As a quick test, I would set all projects to x86. You seem to "mention" that "some" of the COM object works, but just not all.
I will give you a brief description of my software before I ask questions.
So there is a front end C# code which provides the user interface and a back end C++ code that deals with the hardware.
The C# project creates an executable (.exe) file and the C++ project creates a DLL which talk with each other using pinvoke calls (import/export functions). All this worked fine on WEC7.
Now, we are moving to WEC2013 with Toradex. I downloaded the WEC2013 SDK from Toradex’s website and was able to port my code and build it on VS2013.
I copied all the required files on a USB and when I tried running it the C# exe is not able to communicate with the C++ Dll. The error I get is :
missingmethodexception can't find pinvoke dll “xyz.dll”
I have made sure the dll exists at the specified location. The dll also has the required export functions.
First I thought the function parameters in the export functions could be an issue, but I tried calling function which requires no parameter with the same result.
Any help will be really appreciated.
I have a C++ DLL Library. I'm testing the DLL with a C# Project with NET Framework 4.0. In the C++ DLL I'm using some libraries, like POCO, Boost, ODBC, SQLite, SOCI...
It was doing great until I decided to replace the SOCI interface with the POCO one to reduce the number of libraries loaded in the library.
I compiled the PocoData, PocoDataODBC and added them, together with the headers, into the project. The project compiles OK, creates the DLL, and the DLL passes the Dependency Walker tests.
But something strange happens when using the DLL from the .NET Project. The app just closes when executing the DLL methods that contains the Poco::Data part to connect with the database.
There is no exception or error thrown. Not even "application just crashed" from windows. It just stop running and the Visual Studio returns to normal just like if it ended correctly.
I isolated the error and it's enought with any use or call inside the PocoData library to do this error. I can use the library until it tries to use a method that has any call to this. For example:
Session session("ODBC", conn);
Or even this alone:
Poco::Data::RecordSet rs();
So every time the C# calls a method that contains anything from the Poco::Data in the DLL it fails.
Any idea what can be happening?
Windows events log something when the app makes the error, I don't know if it's relevant. It raises two events, the first one is a system hour change between same value (strange), type: Kernel-General.
The second one (about 10 seconds later) is Service Control Manager level Information:
Service Windows Error Reporting Service entered in running state.
I am programming an application in Python which has to use some DLLs originally created from C# code. Generally the usage of such DLLs is working (proven with multiple DLLs, all from the same source). For deployment on other people computers I'm using Py2Exe which also works as intended.
But now I want to use another DLL and have the following problems. If I start the programm and make a call to a function within the DLL, it throws an error saying:
.Net Dll broken because of possibly missing native Dlls.
Now comes the strange part. If I compile the python program into an executable the message does not show up and everything works as intended.
I already tried to identify missing DLLs by comparing the DLL assembly with the ProcessExplorer but they look totally the same. Next thing was to try to set path variables to all Dlls which I am calling directly but this was no solution too.
Other informations which could be interesting are IDE and OS: I'm using Eclipse Indigo with PyDev 2.5 plugin on a Windows 7 machine.
So are there any things I could have overseen or settings which I could try to make it work?
Any suggestions are appreciated.
I'm working with an external DLL to consume an OCR device using a wrapper written by me. I have made tests on the wrapper and it works perfectly. But, when I use a WinForms project to consume the client class of the wrapper (located an another project), an error arises when calling C# methods imported from the DLL (using [DLLImport(...)]) saying that the DLL is not registered.
The error says:
"DLL Library function no found. Check registry install path."
All executions have been made in debug mode.
I've compared both projects configuration. The most relevant difference is that Test project is oriented to Any CPU and WinForms app only points to x86.
What could it be?
Updates
I've tried to register the dll using Regsvr32.exe but it didn't work. I thought about using Gacutil.exe but it required to uninstall all frameworks beyond .net framework 1.1...
I was wondering... at testing environment probably everything works well because testing framework has its dll's or executable files (or something like that) totally registered in windows, so those are trusted dlls. It is possible that debug generated dlls are not trusted by windows and therefore this problem arises?
I've created a form in the same troubling project and then I call the OCRWrapper from a button I've added to it. The OCR's worked!!. Unfortunately, it is difficult to rewrite the first form because we have invested a lot of hours in it; so, I'm still wondering what do I need to change in the troubling form...
I started again the form's development from scratch and added all the components related to it; everything worked well, the OCR read succesfully all data. When I loaded a combo box using a call to an ObjectContext and the error appeared again... I'm using an entity framework connected to Oracle.
I have a theory.
Let's imagine the following situation:
The ocr.dll depends on some other native DLL, lets call it other.dll [A].
In case this is a static dependency, you'll see it through Dependency Walker.
If its dynamic, you can use Sysinternals Process Explorer to monitor DLL loading in your working test project at run-time.
Your ADO.NET provider uses native DLLs under the hood (this is certainly true for ODP.NET) which depend on other.dll [B], which happens to have the same name but is actually a different DLL (or at least a different version) compared to other.dll [A].
Then, in run-time, this might happen:
When you connect to the database, ADO.NET provider dynamically loads its native DLLs, including the other.dll [B].
Then you try to call a function from OCR DLL. The P/Invoke tries to load the OCR DLL dynamically and succeeds, but the other.dll [B] is already loaded and ocr.dll tries to use some function from it, instead from other.dll [A] where it actually exists.
Welcome to DLL hell. So what can you do?
Try varying the order of calls to ocr.dll and ADO.NET provider to see anything changes. If you are (very) lucky, other.dll [A] might actually be a newer version that is still backward-compatible with other.dll [B] and things migh magically start to work.
Try another version of ADO.NET provider.
Try another ADO.NET provider.
Try getting a statically-linked ocr.dll from your vendor (i.e. no run-time dependency on other.dll [A]).
So, the call to the DLL works from a single button, but it does not work from a complex form. I'd say that there is an undefined behavior going on. The question remains whether it is you, that wrote the marshalling incorrectly, or it the DLL that is badly written.
Since we do not have access to the source code of the DLL, maybe you can post the prototype of the function, and all relevant struct definitions, and the DllImport line that you wrote for it?
Google can't find that error message which means(not definitely though :)) it is not a system message but a custom one coming from the code in the dll. So the dll does something dodgy. I guess it tries to double dispatch your call to another function internally.
Few things I suggest you try:
Run a x86 configuration. In the project properties -> Build tab set the platform to x86. this is assuming the dll is an x86 dll.
dumpbin /headers orc.dll
File Type: DLL
FILE HEADER VALUES
14C machine (**x86**)
4 number of sections
4CE7B6FC time date stamp Sat Nov 20 11:54:36 2010
0 file pointer to symbol table
0 number of symbols
E0 size of optional header
2102 characteristics
Executable
32 bit word machine
DLL
This command line should tell you the bitness. In case it is a 64 bit run a 64 bit config instead but I bet it is 32 bit.
Do not include the dll in the project. I guess you do that already. Make sure the dll is in a folder that is in the %PATH% environment variable. When you run this at command prompt:
where ocr.dll
should tell you where the dll is. If it doesn't add the folder where the dll is installed to the %PATH%.