LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Calling extension methods from a dotNET / C# assembly (MongoDB-driver)

Solved!
Go to solution

My recommendation doesn't really count in today's world, but it has been and still is: Stay away from .Net (and ActiveX) whenever there is a chance!

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 11 of 18
(1,819 Views)

Dear Rolf,

 

I tried to go that way, but the LabVIEW MySQL interface via ODBC doesn't really convince me and the advantages of MongoDB regarding being doc-based and NoSQL are pushing heavily in favor of that db.

 

If you have any similar db's with a better LabVIEW interface, please let me know.
We are using the db for accessing pretty static data of various content (therefore MongoDB).

 

Thanks!

Niels Göran

0 Kudos
Message 12 of 18
(1,813 Views)

Well, my course of action in such cases is always to first check for a C interface. MongoDB has one here. Compiling this into a DLL shouldn't be a rocket science project, although it may be a little more effort than just typing "config, make all" on a command line. Smiley Very Happy Then using the Call Library Node to interface to it.

 

I admit it may seem like a lot more work, especially if you don't have C programming experience, but it is by far the leanest and least convoluted way to interface to any software from within LabVIEW. And extra bonus is, that it can be fairly easily made to work for other LabVIEW platforms than Windows too.

 

With .Net you are required to not only learn the development model of the software you want to interface too, but also the whole class interface the developer came up with, which in many cases looks more like an unstructured mess, than a real class hierarchy design. And then you get the extra mess with the different .Net versions that are incompatible on various levels. Sooner or later you end up interfacing to multiple .Net components which need conflicting .Net versions.

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 13 of 18
(1,809 Views)

 

If you are running Windows only then the simplest thing is to go the .NET Framework way since it has the largest BCL set of libraries (many of which target Windows features only of course) and any version of the .NET Framework from 4 onwards inter-operates fine in LabVIEW in every version from 2013 onwards. It is not easy to target .NET in LabVIEW for other OS (at least until LabVIEW Next Gen comes of age, anyway). If running the code on other platforms is a must to you then you should take this into consideration like Rolf has suggested.

 

So as for the best path to take - well, as you'll soon discover (if you haven't already), developers as a whole can be zealots when it comes to their preferences and which way is "right" or "wrong". There are flame wars on the best languages, frameworks, architectures. I haven't had the experiences that Rolf has had (in fact, ironically, I have had the opposite with maintaining legacy apps in C) but that doesn't make his opinion any less valid. Often there is no "right" way but only "the right way for you". It all comes down to your experience and what makes the most sense for your project or, if you have the luxury, developing your interests.

 

So rather than me trying to push you down a path I would suggest you think about what makes the most sense for you based on the project you are working on and where you think it could be headed. If you continue down the .NET route, I can give you further pointers (haha no pun intended). If you want to pursue the C route than Rolf's experience in this area is far greater than mine and he will be able to do the same. If you somehow have the time luxury of doing both well, that would certainly be a good learning experience for you.

0 Kudos
Message 14 of 18
(1,791 Views)

A very good and balanced post, tyk Smiley Very Happy

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 15 of 18
(1,769 Views)

Hey,

we have been hard at work trying to make it work as expected, and I think we have reached at state, that I would like to share with you.
If you may beable to look it over and check if there are some larger issues / design faults, that we should probably rework.

In the attached zip file, you will find the C# project for Visual Studio (2017) and the LabVIEW classes we wrote for utilizing that DLL with dotNET invokes.

Under "C#\mongodb-dll" you will find the Visual Studio project / solution and in "C#\mongodb-dll\MongoLabVIEW\bin\Release" the created DLL...

In "LV" you will find a LabVIEW project (version: 2017, if downgraded to some other version is better, please let me know), that consists of 3 classes (client, database and collection as used in the C# dll) and the necessary function / method wrappers. Furthermore you will find an example of how to communicate with the MongoDB server and find some of the docs in a specific database.

 

Please let me know, what you think and thank you for all your help over the last posts !!

 

Best regards

Niels Göran

0 Kudos
Message 16 of 18
(1,755 Views)

Unfortunately I still only have 2016; but it sounds like you have been able to achieve what you needed so congratulations!

0 Kudos
Message 17 of 18
(1,746 Views)

I down-saved it to 2016 in case anyone is interested....

0 Kudos
Message 18 of 18
(1,741 Views)