Exposing accessor vis as Properties in a .NET assembly

[pcqd]

I want to build a .NET assembly where I can expose Methods and Properties of a .NET class.  I have no problem creating Method vis and having them accessable but I just can't figure out how to get an accessor vi to give me access to the class data via property nodes.  I use the New > VI for Data Member access.. option and I have the Make available through property nodes option checked.  No matter how I configure the Build Specification I can't get the properties I want to be visible.  The only property that is visible is called "InstanceIndex" ...whatever that means?  I am a long time Labview programmer but this is my first venture into .NET assemblies and Classes.

My project is to write an ASCOM compliant driver that will control a stepper motor connected to an Arduino UNO.  ASCOM is a standard established by the Astronomy community for ensuring applications and hardware are compatible.

[pcqd]

Here is a simply zipped project that illustrates my problem.  It contains a class called Human that contains some private data (Height,Weight,Age,HairColor) that I created accessor vis for.  I also create a method called Command.vi  I exported the Command.vi and changed the scope of the accessor vis to Public. I created a build specification which creates a .Net assembly that contains a Human() constructor.  The "What am I doing wrong.vi" illustrates that the accessor vis are doing their job of making the private data accessible via property nodes but only when I references the Human class directly.  When I reference the .Net assembly constructor called Human() there are no properties available except for the InstanceIndex property.

Any help would be much appreciated.

Peter

[Kelsey_Weaver@NI]

Hi Peter,

Have you seen the following Help document about creating .NET assemblies? There's a section toward the bottom that talks about LabVIEW Classes in particular with this application. 

http://zone.ni.com/reference/en-XX/help/371361H-01/lvhowto/building_a_net_assembly/

Try adding the Human Class methods (Read Age.vi, Write Hair Color.vi, etc) in the Source Files section when you build the assembly. Let me know if this helps.

- Kelsey

[pcqd]

Kelsey,

Thanks for taking a crack at this.  I tried a few variations...none worked.

If I add the accessor vis as exported VIs they appear as methods...not as properties.  Also the build specification forces me to choose unique names for the read and write vis.

I tried adding the accessor vis to the Always Included section...nothing changed.  I even tried adding the class to the Always Included section...same result.

Two things I did notice are as follows:

When I run a vi that references the Human constructor in the .NET assembly the program pauses for about a second and then shows a file dialog as it looks for the Human class?  It eventually finds Human.lvclass but this behaviour is not wanted.

I also have configured the build specification to generate a log file...here are the contents of this log file:

Note: For this particular log I only had the command.vi specified as an exported vi...the "Always Included" section was empty.

12/16/2013 7:56:25 PM
[General]
Project: C:\Program Files (x86)\National Instruments\LabVIEW 2012\instr.lib\TestProj\Net Properties.lvproj
Target: My Computer
Build Specification: My Interop Assembly
OS: Windows NT 6.1

[Source Files]
C:\Program Files (x86)\National Instruments\LabVIEW 2012\instr.lib\TestProj\Human.lvclass 12/14/2013 9:46:08 PM 1.0.0.1
C:\Program Files (x86)\National Instruments\LabVIEW 2012\instr.lib\TestProj\Command.vi 12/14/2013 9:30:26 PM 1
C:\Program Files (x86)\National Instruments\LabVIEW 2012\instr.lib\TestProj\Read Age.vi 12/14/2013 9:44:31 PM 50
C:\Program Files (x86)\National Instruments\LabVIEW 2012\instr.lib\TestProj\Write Age.vi 12/14/2013 9:44:24 PM 46
C:\Program Files (x86)\National Instruments\LabVIEW 2012\instr.lib\TestProj\Read HairColor.vi 12/14/2013 9:28:23 PM 50
C:\Program Files (x86)\National Instruments\LabVIEW 2012\instr.lib\TestProj\Write HairColor.vi 12/14/2013 9:28:23 PM 46
C:\Program Files (x86)\National Instruments\LabVIEW 2012\instr.lib\TestProj\Read Height.vi 12/14/2013 9:28:23 PM 50
C:\Program Files (x86)\National Instruments\LabVIEW 2012\instr.lib\TestProj\Write Height.vi 12/14/2013 9:28:23 PM 46
C:\Program Files (x86)\National Instruments\LabVIEW 2012\instr.lib\TestProj\Read Weight.vi 12/14/2013 9:28:23 PM 50
C:\Program Files (x86)\National Instruments\LabVIEW 2012\instr.lib\TestProj\Write Weight.vi 12/14/2013 9:28:23 PM 46

[Output File Version]
InteropAssembly.dll 1.0.0.9

[Output Files]
C:\Program Files (x86)\National Instruments\LabVIEW 2012\instr.lib\TestProj\Build\NetAssembly.dll\InteropAssembly.dll 12/16/2013 7:56:26 PM
C:\Program Files (x86)\National Instruments\LabVIEW 2012\instr.lib\TestProj\Build\NetAssembly.dll\InteropAssembly.aliases 12/16/2013 7:56:26 PM
C:\Program Files (x86)\National Instruments\LabVIEW 2012\instr.lib\TestProj\Build\NetAssembly.dll\InteropAssembly.ini 12/16/2013 7:56:26 PM

12/16/2013 7:56:26 PM

I have noticed that no matter what source files I specified, this log looked the same.  For [Source Files] you will notice that all of the vis associated with the Human class are mentioned...even the Human.lvclass is mentioned.  The numbers immediately following the date/time stamps are probably a clue.  The command.vi is assigned a "1".  The accessor vis are assigned "46" or "50" depending on whether they are read or write. 

Even if I add the accessor vis into the Exported vis section of the build specification these accessor vis are still identified in the log file using the "46" and "50" descriptors.

This is going to take some digging.

Peter

[Kelsey_Weaver@NI]

Peter,

Yes I agree, this is pretty interesting behavior. I was able to access the VI's using invoke nodes (just as you mentioned you were able to access them as methods, not as properties) when they were included in the list of exported VI's. Unfortunately this seems to be the way that .NET assemblies function with LabVIEW OOP. The VI's are handled as methods if accessed through the constructor node, but accessed as properties when you simply instantiate a LVOOP class. 

Is there a particular reason you want to access these properties/methods using a .NET assembly as opposed to creating an object explicitly as you had done previously? Or are you simply testing the functionality of the created assembly in LabVIEW before you use it somewhere else? It may behave differently when accessed from another environment that handles .NET assemblies. 

Perhaps take a look at the following KnowledgeBase articles to further troubleshoot your additional questions: 

http://digital.ni.com/public.nsf/websearch/DC41DCDA972642CF8625787E00732DDD

http://zone.ni.com/reference/en-XX/help/371361K-01/lvconcepts/net_defaults/

Nothing seems too obvious to me as far as explaining the log file behavior you were seeing. Maybe look into the versions of .NET Framework and CLR that you have by default. Maybe this is introducing some unexpected behavior.

Best,

Kelsey

[pcqd]

Kelsey,

I was hoping to build a .Net assembly that adhered to the ASCOM standards.  These are standards developed for the Astronomy community.  They are an attempt to standardize how manufactures write hardware drivers for telescopes and astronomical equipment.  The standard simply requires a .Net assembly to provide a consistent way of communicating with each vendors hardware.   I have researched using several example .Net assemblies provided as part of the ASCOM developers SDK and have found that they require exported methods for specific actions and properties for view such things as "driver version" or "description".  This makes it very easy to purchase astronomy software and be able to configure it for whatever telescope, etc. you may own.  The ASCOM standard is based upon Windows COM and is described as being very simple to implement.  Not being able to do this using Labview is disappointing.  I know I can write a simple vi to do what I need as a stand-along app.  I only need to control a small stepper motor connected to an Arduino...I already have this done.

I think an important behaviour to persue is the one second pause followed by a search looking for Human.lvclass.  If you read the document at http://zone.ni.com/reference/en-XX/help/371361H-01/lvhowto/building_a_net_assembly/ you will find the following text.

LabVIEW Classes

You can export the member VIs of a LabVIEW class. In LabVIEW, these VIs require the owning LabVIEW class as an input. Therefore, when you export these VIs to a .NET interop assembly, LabVIEW must create an equivalent .NET class definition in the assembly. The .NET class definition contains a static method for each member VI. Each of these static methods requires an instance of the newly defined .NET class as a parameter. LabVIEW does not export the private data of the owning LabVIEW class.

The behaviour I am seeing makes me think that Labview is not doing this.  I don't see any error messages during the build and I see this file search behavior every time I run a vi that contains the constructor node.  Figuring out why the file searching is happening may be key to learning what is happening.

Peter

[Kelsey_Weaver@NI]

Peter,

This may be an obvious suggestion, but are you sure you have navigated the constructor node to the InteropAssembly.dll you created and selected the Human class from the list? I didn't experience this behavior when I ran the example on my machine, so it may be specific to your build or machine for some reason. Try deleting the "Build" folder that is created and starting with a fresh build. Be sure to rename the assembly before you re-build. Additionally, what operating system do you have?

Let me know of any updates!

- Kelsey

[pcqd]

Kelsey,

I am using Windows7 64b with Labview 2012 32b.  I see that v4.0 .Net framework is installed but haven't figured out how to determine what version of CLR I have.  I did notice that earlier on I did not get the pause and file dialog appearing.  I did read where the correct version of a .NET assembly is not always what Labview is accessing.  This behaviour may have started when I began auto-incrementing the version number in the build spec.  I will delete the folder as you suggested and rename the build.

When I configure the constructor node I alway browse to the dll and then check it's creation date to be sure Im dealing with the most current version...but that may not be strong enough to ensure Labview isn't using a cached filename.  I did notice that Labview seems to have first created a unique file folder to hold the .NET assembly and it then searches for Human.lvclass.

I will let you know what develops.

Peter

P.S. I have also activated a service request via my SSP.  Minor Coto is handling it

 (Reference#7396482) .NET assembly accessors vis via  properties

When I first put in the service request the response prompted me to ask my question thru this forum

[Kelsey_Weaver@NI]

Hi Peter,

A colleague of mine discovered something interesting when he duplicated the issue on his machine. When you create LabVIEW classes and their subsequent properties/methods, the LabVIEW environment allows you to include spaces in the names (in fact, the properties for read and write be default will include a space). However, most other environments that use OOP do not allow spaces. The .NET protocol for classes, in fact, does not allow spaces. So when it creates the assemblies, it adds an underscore into the "Read Age" method, for example, as well as the others. I wondered if maybe you had included a space accidentally at the end of the "Human" class name. This would cause the behavior you're seeing where it searches for the class name for a while before finding it. At the very least, try substituting underscores where you have spaces in the creation of the accessor VI's. Another interesting thing to note is that each time you re-build (with the same build name) it either will not allow you to rebuild, or it will add ANOTHER underscore into the class names and properties where a space was once found. So if you build the assembly twice (using the same name), you'll have two underscores where there originally was a space in the name. 

So in conclusion, avoid spaces in the naming convention of your classes/properties/methods. This will help your code be more compatible with .NET environments and minimize the need for a search. 

Let me know if this helps!

Kelsey

[pcqd]

Kelsey,

I have tried many, many variations and nothing works.  Then I thought of looking into the .net examples provided with LV2012.  There are two .net assemblies referenced in these examples.

C:\Program Files (x86)\National Instruments\Labview 2012\examples\comm\dotnet\Calculator.dll

This .net assembly only contains methods that can be exposed via invoke nodes.  It has no properties.

C:\Program Files (x86)\National Instruments\Labview 2012\examples\comm\dotnet\EventExample.dll

This .net assembly contains both methods and properties which is exactly what I am after.

What would it take to convince National Instruments to release the projects to build these assemblies?  At the very least it demonstrates exactly what I am looking for and may illustrate a potential corrective action to follow up on.  I have toiled many, many hours trying to figure out how exactly what is present in the EventExample.dll

I will ask Minor Coto the same question.  Hopefully something will come of it.

Thanks for sticking with me...have a very happy holiday

Peter