NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

C# WPF AppDomain

Solved!
Go to solution

Hi, 

 

I'm trying to figure out a way to build the simplest WPF usercontrol that will handle all the Teststand stuff.

I'm trying to rely on the WinForm basic example and I'm hitting some challenges that leads me to ask help in here.

 

What is the benefit of launching the application in a new AppDomain ?

Is there anyway I can achieve that with a user control in WPF ?

 

Is there any concerns of launching teststand on the same appDomain than the WPF application ?

 

I'm a little bit desperate as WinForms are less used in those days (at least not with people I work/worked with) and I need to continue using it and would like to have solutions to embed Teststand in WPF.

 

Many thanks to any relevant help,

It is much appreciated

 

 

0 Kudos
Message 1 of 4
(1,719 Views)
Solution
Accepted by ebonneau9

The main reason for launching the app in a separate AppDomain is to avoid false leak detection errors reported by the TestStand runtime engine. With Windows Forms at least, even clearing all .NET references to TestStand objects and forcing garbage collection before freeing the TestStand engine was not sufficient to avoid false memory leak reporting. That is likely because Windows Forms was holding onto some TestStand objects indirectly, likely due to static member variables somewhere in the Windows Forms code. Moving all of that code into a separate appdomain and unloading that appdomain before destroying the engine was a workaround to that issue. It's not strictly necessary and you can even avoid the false leaks as long as you don't hold onto any TestStand objects at static/global scope (and WPF doesn't do so) then ensure no .NET variables reference TestStand objects (other than the engine) and then do GC.Collect() and GC.WaitForPendingFinalizers twice in a row (needed due to how the garbage collector works) then call Marshal.FinalReleaseComObject() on the last reference to the engine when you are done with it.

Message 2 of 4
(1,686 Views)

This seems to me a perfect answer.

Just to confirm what you are saying regarding WPF : 

Are you saying that WPF don't hold onto TestStand objects at static/global scope and Windows Forms does?

 

If so, I'm okay to continue on the same AppDomain for now as everything runs smoothly and well.

I thought there was real big issues with not running in the same AppDomain but since I control the teststand variables, risk of getting into trouble are very low at this point.

 

Thanks again for you answer.

0 Kudos
Message 3 of 4
(1,669 Views)

Just to confirm what you are saying regarding WPF : 

Are you saying that WPF don't hold onto TestStand objects at static/global scope and Windows Forms does?


Windows Forms seems to, whether or not WPF does I don't know. If you start getting leak errors reported by the engine when it's destroyed that you are pretty sure aren't real leaks, then you might be hitting a similar issue. You would need to use some sort of memory profiling tool to be sure. If you don't get memory leaks reported when you destroy the engine then you are probably ok.

 

-Doug

0 Kudos
Message 4 of 4
(1,646 Views)