Catch Exception in c# with .Net Assembly Built in Labview

[zmod_cz]

Hello, I build a simple .net assembly using the application builder in labview 2016. I have attached the vi which simple takes an input string and returns the string.

Using Visual Studio 2015, I added the .net assembly (its called InteropAssembly.dll) as a reference in my c# application. The class was called LabVIEWExports and the method name was set as lvstring in the application builder. I was able to successfully run the vi using the following C# code in my visual studio project:

try {
     InteropAssembly.LabVIEWExports.lvstring(lvStringInTextBox.Text, out lvstringOut);        
     lvStringOutTextBox.Text = lvstringOut;
}
catch (Exception ex) { 
    System.Diagnostics.Debug.WriteLine("hello"); 
    System.Diagnostics.Debug.WriteLine(Newtonsoft.Json.JsonConvert.SerializeObject(ex, Newtonsoft.Json.Formatting.Indented));
}

My visual studio project allows the user to type in a string in a text box and click a button. When that button is clicked it implements the try/catch block above and puts the text returned from the labview vi call into another text box. This all works fine with no errors.

My concern however is that according to the documentation in the following links: http://zone.ni.com/reference/en-XX/help/371361M-01/lvhowto/charac_net_interop/ https://zone.ni.com/reference/en-XX/help/371361K-01/lvdialog/advanced_net_page/

for labiew 2012 and later (I'm using 2016) regarding error in and error out clusters...

"When LabVIEW generates a .NET method for a VI, LabVIEW does not export the error in and error out clusters as parameters of the new method. Instead, the new method throws a .NET exception if an error occurs while the method is executing. This exception contains the same information as the error cluster."

This appears to say that when my vi is run within the c# code, an exception should be thrown since I wire a custom error cluster to the error out indicator. However, no exception is thrown or caught in the c# code ? Why?

[zmod_cz · Accepted solution]

I apologize. The documentation is correct and my C# code does throw the exception when an error is wired to the output error cluster. The reason I thought it wasn't working was due to the visual studio reference using an older copy of the .net assembly (before I added the error out cluster).

[JonP]

I have been trying to get this to work myself using LabVIEW 2015, but no luck. I am doing exactly what you did and writing a fixed error to the error cluster indicator of my top level interface VI. Did you do anything else in the process of getting this to work that might have a bearing? I am using Visual Studio 2013.

[JonP]

It's OK, I've got it. You must do all of these things before it will work:

1. Have an output error cluster in the top-level VI. If a lower-level VI generates an error that is not propogated back to the top-level VI it will not work.
2. WIRE THE ERROR CLUSTER TO A TERMINAL! This was my mistake, I was assuming I didn't need to do this as the .NET interface did not return the error cluster.
3. It's no good just rebuilding the target assembly in LabVIEW. You have to remove the VI from "Exported VIs" list and then add it again before the build realises the interface is different. (This is true for any interface change it seems - it might be better in a later version of LabVIEW though).

[zmod_cz]

Hi,

not sure in the difference between 2015 and 2016 but I ended up solving this by specifically referencing the exception like this:

try

{

     your dll method...

}

catch (NationalInstruments.Labview.Interop.VIAssemblyException ex)

{

  var systemEx = new Exception(ex.Message, ex.InnerException) { Source = ex.ErrorSource};

throw systemEx;

}

make sure to add the NationalInstruments.Labview.Interop.dll from the appropriate LV runtime folder as a reference in your project. 

[JonP]

Thanks for the reply but as you see I managed to get it to work using good old trial & error! I did not find it necessary to catch the exception specifically, catching the <code>Exception</code> class works OK. Hopefully my list of gotchas will help others in the same situation.