LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

.NET DNDomain.DomainAgent exception

I wrote a VI that uses .NET (written in C#) objects. In the VI I have a while-loop that doesn't call any .NET objects. The loops executes for over 5 minutes. After the elapsed time if I call one of my .NET object, I get a "Cannot load type DNDomain.DomainAgent" exception. After researching the problem I found out that this class is a LabView 7.0 class.

As a workaround I wrote a 'Ping' method in my object that does nothing, but get's called in my loop to make sure the the object still works after the loop.

The DomainAgent looks like a CAO (.NET Client-Activated-Object) and CAOs have a default lease time of 5 min which coincides with my timeout length. this may be a coincidence but you never know.

Anybody have any leads on th
is Please?
Message 1 of 10
(4,143 Views)
Hi,

Copy the attached DNDomain.dll & DNCompInfo.dll to the resource directory under LabVIEW directory. This will probably solve your problem.

Good luck.

Feroz
Download All
Message 2 of 10
(4,140 Views)
Thanks for the files, but unfortunately that didn't solve my problem. I still get the cannot find type DNDomain.DomainAgent error after waiting ~5-10 minutes.
0 Kudos
Message 3 of 10
(4,138 Views)
Hi,

Have you tried this with other .NET objects? If yes, please email your code to NI. We'll try to reproduce this and figure out what could be causing this.

Feroz
0 Kudos
Message 4 of 10
(4,138 Views)
Thanks for your article it helped me to understand that I have the same problem. Your solution is also the problem solver in my case.
-Edi
0 Kudos
Message 5 of 10
(4,062 Views)
You are correct - the DomainAgent is a CAO and in 7.0 we didn't set the lease timeout. This was fixed in LV 7.1 (we set it to infinite timeout since we controled both the proxy and the server). The workaround is pretty much what you have already done.

Great job figuring it out! .NET Remoting issues can get pretty hairy.
0 Kudos
Message 6 of 10
(4,057 Views)
 

Brian, would you please give me an idea of what needs to be excercised by this Ping? I'm doing primarily UDP communications and am using .NET for secure string encoding/decoding("RijndaelManaged" class, "ICryptoTransform" object). This is the area in my code generating the exception. I only get the exception when running compiled code.

I don't quite understand how this times out as a new instance is created and destroyed with each UDB string that is encoded/decoded - but that's somewhat beside the point!

Any assistance on what to excersize with a ping, and instructions on resetting this error without exiting and restarting the code would be helpful. (currently that is the only way I can keep the exception from occuring with each .NET call).

Since this is fixed in 7.1, is their a patch available or anything I can do to fix this timeout in LV7.0?

Thank you for your time!

0 Kudos
Message 7 of 10
(3,979 Views)
I don't think you are having the same problem. The ping described above is to keep a .NET remote object alive, and if you're using UDP, you're not using .NET remoting.
 
My guess is that you're getting an exception for something else, but unfortunately there isn't a lot of information dumped in LV 7 regarding the nature of the exception.
 
When you say it only happens in compiled code, I should assume you mean a built EXE? If that is the case, are all the assemblies you are using in .NET in the GAC? If there are any DLLs that you point to for your .NET calls, make sure they are in the same directory as your EXE when you run.
 
Does that help?
0 Kudos
Message 8 of 10
(3,971 Views)
Thanks for the reply. You are correct that the problem occurs in a built application (.exe). I'm not using a remote .NET object (I don't think!) - I simply require the .NET framework be installed on the machine which runs the .exe application. In that way, I'm getting to the .NET dll's. Do I still need to include the .NET dll's in the same directory as the .exe in the distributed application?
 
I'm using LV calls for UDP comm, but using .NET for AES encrypt/decrypt capability.
 
This problem sounded very familiar to mine in that I only get the error "Cannot load type DNDomain.DomainAgent, DNDomain, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null." after a period (several minutes) of inactivity, and then attempting to restart activity within application. The ping approach (simply creating a .NET object, then destroying it) actually seems to prevent the problem from occuring.
 
I hope this provides a bit more insight into the issue.
0 Kudos
Message 9 of 10
(3,968 Views)
Ah, I understand your situation better now. Yes, you are indeed affected by the same issue - the DomainAgent is being destroyed after five minutes of inactivity. The solutions are to either create a VI in your application that loops continually - doing some .NET call at least once every 4 minutes or so - to keep the DomainAgent alive, or upgrade to LV 7.1/8.0.
0 Kudos
Message 10 of 10
(3,958 Views)