.net constructor timeout?

[Mellobuck]

Hello,

I am using a .NET constructor node in LV 2009 to connect to an existing third-party .dll. If the XML file the DLL is using to get it's configuration data is OK, the .NET constructor executes quickly and immediately gives me the .NET reference to use. However, is something is amiss with the DLL setup, the constructor takes 40-60seconds to execute, but then gives me no error. Is there any way I can set a 'Timeout' or something similar when using the constructor node so that if it is taking too long to execute, I can stop and produce an error or something?

Thanks,

Mello

[GerdW · Accepted solution]

Hi Mello,

you could measure the time needed to execute the constructor and decide on that value...

[smercurio_fc]

You can't set a timeout on the constructor, so you would need to resort to what GerdW mentioned.

I am confused by one thing. You said "if something is amiss with the DLL setup". Would this be just the XML file, or something else? Can you check the XML file yourself before calling the constructor?

[Mellobuck]

Hello,

Yes it would be the XML file. If the DLL is pointing towards an incorrect IP, for example. I could parse the XML file myself, it is the setup file for Windows Communication Foundation. I am currently testing GerdW's method, and will let you know.

-Mello

[Mellobuck]

It seems that I tried to take one step forward and went five steps back.

Now, the constructer node just keeps giving me an error 1172. This happens wherever I try and use it, even in a new project with a new VI, only containing the node. This is only when I browse for the path, the built-in .NET functions work fine (Timer, Calendar etc.)

These were working this morning. When the XML, as above, was set up correctly no problems or errors on the node. We even rolled back the .DLL's to where we had left them before we started this morning, with no help.

I really don't even know where to look here, I have repaired labview and restarted a number of times...

-Mello

[Ben]

reboots maybe required if the dll is registered. (confession: outside my comfort region)

Dr Gray's Nugget here offers other methods for loading, they may help.

Ben

[smercurio_fc]

With .NET private assemblies the most likely problem with constructors is that of dependencies on other private assemblies.

What do you mean by "This is only when I browse for the path". Which path? The path of the private assembly?

[Mellobuck]

By "Only when I browse for Path" I meant the Browse button at the top of the .net dialog that let me browse to the private assembly.

The error is gone, I hadn't copied the XML setup file for the new test. Now back to testing what I had originally planned...

-Mello

[Mellobuck]

Re: Ben

Explicit loading of the library with Dr. Gray's VI was successful, but had to effect on the error in the constructor node.

[Ben]

---

Mellobuck wrote:

Re: Ben

Explicit loading of the library with Dr. Gray's VI was successful, but had to effect on the error in the constructor node.

---

I suspect that should read " but had NO effect...".

If you know you are loading teh right dll and other calls work (double check to be sure!) then I have to ask if the dll is healthy.

Ben