Develop Reference

COM-object was released unintendedly

I have a helper-class for my unit-tests that share a reference to an COM-object in memory:
public class UnitTestGeometryProvider
{
public static readonly IGeometry Geometry = Deserialize();
}
The geometry is deserialized from a Xml file which is stored as a resource file and appended to the project. Afterwards it is wrapped into a COM object:
public static IGeometry Deserialize()
{
return (IGeometry) new XMLSerializerClass().LoadFromString(myXDoc.OuterXml, null, null);
}
Now I have two test-methods that use the geometry stored within this class:
[TestClass()]
public class MyTest
{
[TestMethod()]
public void FirstTest()
{
var p = UnitTestGeometryProvider.Geometry;
}
[TestMethod()]
public void SecondTest()
{
var p = UnitTestGeometryProvider.Geometry;
}
}
When running the second one I get a COMException:
COM object that has been separated from its underlying RCW cannot be used
I wonder why the reference to the COM-object is released as it is marked static in UnitTestGeometryProvider and I do not explicitly release it. So even if the managed resource to the instance would go out of scope (which is does not at it is static), the underlying COM object should go away only when all my tests finished or more general when the application terminates, or do I miss anything?
I am using ArcObjects and Visual NUnit.

Due to the comments by Hans Passant I found the actual problem.
Obviously the Visual-NUnit-Framework decides to create a separate thread for every test. Thus whenever I create a COM-object - be it static or not - this object lives on this single thread and cannot be used in another one. If the thread dies also does the COM-object or to be more precise the reference to it. This leads to the GC kicking in throwing the COM-object away as no more managed references to it exist within that thread.
The solution is pretty straitforward: I changed the static field to instance-members and created an instance-member of type UnitTestGeometryProvider within my test-class. Thus a new provider is generated by every test.
However this solution is quite annoying because the Geometry-property has to be initialized and therefor the Deserialize-method runs for every test instead of only once for all tests.
I don´t know if there is a thread-safe solution to not kill the reference to the COM-object when the first thread that intialized it dies.

.NET Remoting and HttpContext.Current

We have a plugin system where the plugin code runs on a separate AppDomain from the main process, using .NET remoting for the objects to communicate.
One class is similar to HttpContext.Current (which also suffers from the problem) (edit, the actual implementation):
public class MyClass
{
public static MyClass Instance
{
get
{
if(HttpContext.Current != null)
return HttpContext.Current.Items["MyClassInstance"];
}
set
{
if(HttpContext.Current != null)
HttpContext.Current.Items["MyClassInstance"] = value;
}
}
}
Then, we have a communicating object which inherits from MarshalByRefObject:
public class CommunicatingClass : MarshalByRefObject, ICommunicatingClass
{
public void DoSomething()
{
MyClass.Instance.DoSomething();
}
}
The CommunicatingClass is created on the main AppDomain, and works fine. Then, there's the plugin class, which is created on its AppDomain, and given an instance of the CommunicatingClass:
public class PluginClass
{
public void DoSomething(ICommunicatingClass communicatingClass)
{
communicatingClass.DoSomething();
}
}
The problem is, that even though CommunicatingClass resides on the main appdomain (verified with the Immediate Window), all of the static data such as MyClass.Instance and HttpContext.Current have disappeared and are null. I have a feeling that MyClass.Instance is somehow being retrieved from the plugin AppDomain, but am unsure how to resolve this.
I saw another question that suggested RemotingServices.Marshal, but that did not seem to help, or I used it incorrectly. Is there a way that the CommunicatingClass can access all static methods and properties like any other class in the main AppDomain?
Edit:
The PluginClass is given an instance like this:
public static PluginClass Create()
{
var appDomain = GetNewAppDomain();
var instance = (PluginClass)appDomain.CreateInstanceAndUnwrap(assembly, type);
instance.Communicator = new CommunicatingClass();
return instance;
}
Edit 2:
Might have found the source of the problem. MyClass.Instance is stored in HttpContext.Current.Items (see above edit).
Is there any way at all that HttpContext.Current can access the correct HttpContext? I'm still wondering why, even though it is being run in HttpContext.Current's AppDomain, CommunicatingClass.DoSomething, when calling MyClass.Instance, retrieves stuff from PluginClass' AppDomain (if that makes any sense).

So my co-worker and I worked this out, finally, with a bunch of help from Reflector.
The main problem is that HttpContext.Current is null when accessed via a remoting call.
The HttpContext.Current property is stored in an interesting manor. A few nested setters down, you reach CallContext.HostContext. This is a static object property on a CallContext.
When the CallContext is set, it first checks if the value is an ILogicalThreadAffinitive.
If it is, it stores the value in the current thread's LogicalCallContext.
If it's not, it stores the value in the current thread's IllogicalCallContext.
HttpContext is not an ILogicalThreadAffinitive, so it is stored in the IllogicalCallContext.
Then, there's remoting.
We didn't dig too far in to its source, but what it does was inferred from some other functions.
When a call is made to a remote object from a different AppDomain, the call is not directly proxied to the original thread, running in the exact same execution context.
First, the ExecutionContext of the original thread (the one containing HttpContext.Current) is captured, via ExecutionContext.Capture (more in this in a bit).
Then, the ExecutionContext returned from Capture is passed as the first argument to ExecutionContext.Run, esentially forming the code:
Delegate myRemoteCall; //Assigned somewhere else in remoting
ExecutionContext.Run(ExecutionContext.Capture(), x => { myRemoteCall() }, null);
Then, completely transparently, your code in the remote object is accessed.
Unfortunately, HttpContext.Current is not captured in ExecutionContext.Capture().
Here lies the essential difference between an IllogicalCallContext and a LogicalCallContext.
Capture creates a brand-new ExecutionContext, essentially copying all of the members (such as the LogicalCallContext) in to the new object. But, it does not copy the IllogicalCallContext.
So, since HttpContext is not an ILogicalThreadAffinative, it cannot be captured by ExecutionContext.Capture.
The solution?
HttpContext is not a MarshalByRefObject or [Serializable] (probably for good reason), so it cannot be passed in to the new AppDomain.
But, it can cross ExecutionContexts without problem.
So, in the main AppDomain's MarshalByRefObject which is given as a proxy to the other AppDomain, in the constructor give it the instance of HttpContext.Current.
Then, in each method call of the new object (unfortunately), run:
private HttpContext _context;
private void SyncContext()
{
if(HttpContext.Current == null)
HttpContext.Current = _context;
}
And it will be set without problem. Since HttpContext.Current is tied to the IllogicalCallContext of the ExecutionContext, it will not bleed in to any other threads that ASP.NET might create, and will be cleaned up when the copy ExecutionContext is disposed.
(I could be wrong about much of this, though. It's all speculation and reflection)

I believe you'll need to derive MyClass from MarshalByRefObject as well.

AppDomain Unload killing Parent AppDomain

I am having trouble figuring something out about my AppDomain.Unload(...) call. I have a detailed explanation with code from my earlier question. As it turns out, I was performing a couple of steps that apparently, I don't need to. However, I am fairly certain that when an AppDomain is created and then held in a collection:
private static Dictionary<string , AppDomain> HostDomains;
void StartNewDomain(string domainName)
{
AppDomain domain = AppDomain.CreateDomain(domainName);
HostDomains[domainName] = domain;
}
...when you are done with it, you must unload it:
if (HostDomains.ContainsKey(domainName))
{
AppDomain.Unload(HostDomains[domainName]);
HostDomains.Remove(domainName);
}
then remove domain from the collection.
When I unload the domain, however, the entire application is ending. If I remove the unload, all is well...and we are simply left with removing the domain from the collection. But I fear that my child AppDomain is not really unloaded. It may eventually get GC'd I guess, but that doesn't give me a warm fuzzy.
The child AppDomain assembly (a Windows Form application) is started asynchronously via an interface (IModule) that is referenced in my adapter class which inherits MarshalByRefObject. I am wondering if this reference to IModule's Start() (which the plugin module assembly implements) is not marshaling properly (because of my implementation). So, when the Shutdown() method is called, the entire application dies. Should I make my IModule an abstract class instead so it should inherit MBR as well? Puzzled...
After looking at my code:
// instances the module for access to the module's Start() method
IModule module = (IModule)domain.CreateInstanceAndUnwrap(
ModuleManager.Modules[modName].Name,
ModuleManager.Modules[modName].EntryPoint.FullName);
...my fear is that since IModule is an interface, even though I am creating an instance in a child domain, the assembly is leaking into my main AppDomain. Therefore, when I attempt to unload the child domain, both domains are being unloaded. Would this be correct? And what would likely be the best solution to provide Start() & Stop() methods via the MBR (adapter) object?
UPDATE: see my answer below for changes --
Okay, there is no leaking -- everything inherits MBR:
Host : MarshalByRefObject -- instances the ModuleAdapter in a new AppDomain
ModuleAdapter : MarshalByRefObject -- IModule interface, interface methods (Start,Stop)
MyModulePlugin : MarshalByRefObject -- Application.Run(myForm)
Am I doing something wrong still? I've tried several things and it just seems to be wrong or incomplete. When I tell the ModuleAdapter to shutdown, it calls AppDomain.Unload(AppDomain.CurrentDomain) and the Host domain stops as well. I am still getting some first chance exceptions on the application exit. But the form (myForm) has been told to .Close().
So, I am still looking for the correct way of doing this...

As I suspected, instancing with the IModule interface in the primary domain causes a leak. In order to do this properly:
AppDomain domain = AppDomain.CreateDomain(domainName);
HostDomains[domainName] = domain; // put in collection
ModuleAdapter adapter = (ModuleAdapter)domain.CreateInstanceAndUnwrap(asmName , typeName);
where ModuleAdapter inherits MarshalByRefObject. Then:
adapter.Execute(moduleAssembly , moduleType);
Inside the ModuleAdapter class:
public void Execute(string Name, string EntryPoint)
{
module = (IModule)AppDomain.CurrentDomain.CreateInstanceAndUnwrap(Name , EntryPoint);
}
I do welcome comments or additional answers for a better way.
After moving the instancing to the ModuleAdapter class, we are still having the issue with AppDomain.Unload killing the entire application. I was wondering if this is because in the module plugin we are using Application.Run(myForm) - then when we shutdown we call myForm.Close(). Obviously this shuts down the application so I was wondering if the myForm.Close() also 'unloads' the AppDomain.

AppDomain and threading

Basically, from what I've understood of the little I've managed to search up on the internet, threads can pass between AppDomains. Now, I've written the following code:
const string ChildAppDomain = "BlahBlah";
static void Main()
{
if (AppDomain.CurrentDomain.FriendlyName != ChildAppDomain)
{
bool done = false;
while (!done)
{
AppDomain mainApp = AppDomain.CreateDomain(ChildAppDomain, null, AppDomain.CurrentDomain.SetupInformation);
try
{
mainApp.ExecuteAssembly(Path.GetFileName(Application.ExecutablePath));
}
catch (Exception ex)
{
// [snip]
}
AppDomain.Unload(mainApp);
}
}
else
{
// [snip] Rest of the program goes here
}
}
This works fine and everything is clicking into place... The main thread passes through into the new version of my program and starts running through the main application body. My question is, how would I go about getting it to go back out to the parent AppDomain? Is this possible? What I'm trying to achieve is sharing an instance of a class between the two domains.

You cannot share instances of classes directly between AppDomains. To do so, you should derive the class from MarshalByRefObject and use remoting to access the instance from the other AppDomain.

An object in .Net can only exist in one AppDomain. It is not possible for it to exist in 2 AppDomains at the same time.
However you can use .Net Remoting to push a proxy of a .Net object into several AppDomains at once time. This will give your object the appearance of being in multiple domains. I believe this is what you are looking for.
There are many tutorials available online. Google for ".Net Remoting Tutorial" and that will put you on teh right track.
http://www.beansoftware.com/NET-Tutorials/NET-Remoting-Tutorial.aspx
http://msdn.microsoft.com/en-us/library/72x4h507(VS.80).aspx

Passing data across appdomains with MarshalByRefObject

I'm having a little trouble passing some data between two .NET appdomains and I'm hoping someone on here can help me.
Basically what I have is a main application (Main) which loads assembly A and B into it's main domain, then when I run a plugin(C) Main calls a create domain method on B which creates a new domain and loads C and a instance of B into it, so that C can only access B and not the others.
B contains a pointer to the IDispatch of Main but only it seems to get it after it is loaded into the new domain with C. What I am trying to do is send a copy of the pointer from the new domain instance of B and send it to A which is still running in the default domain.
Just for the record I control A,B and C but not Main
Sorry if this is a bit hard to understand I tried my best to explain it.
Code:
In A:
public class Tunnel : MarshalByRefObject
{
public void SetPointer(int dispID)
{
IntPtr pointer = new IntPtr(dispID);
}
}
In B:
//Call by Main after loading plug in but after A.dll is loaded.
public void CreateDomain()
{
AppDomain maindomain= AppDomain.CurrentDomain;
tunnel = (Tunnel)maindomain.CreateInstanceAndUnwrap(typeof(Tunnel).FullName,
typeof(Tunnel).FullName);
AppDomain domain = base.CreateDomain(friendlyName, securityInfo, appDomainInfo);
//Load assembly C (plug in) in domain.
// C uses B so it loads a new instance of B into the domain also at the same time.
// If I do this here it creates new instance of A but I need to use the one in
// the main domain.
//tunnel = (Tunnel)domain.CreateInstanceAndUnwrap(typeof(Tunnel).FullName,
typeof(Tunnel).FullName);
tunnel.SetPointer(//Send data from B loaded in new domain.)
}
So at the end it looks something like this:
Default Domain:
Main.dll
A.dll
B.dll
Plug in Domain:
B.dll
C.dll

In your code above you are calling
AppDomain.CurrentDomain.CreateInstanceAndUnwrap(...)
This is simply a round-about way of creating an object in the current domain, same as if you just called the constructor. You need to call that method on a remote domain, ie.
AppDomain domain = AppDomain.Create(...)
Tunnel tunnel = (Tunnel)domain.CreateInstanceAndUnwrap(...)
If you then call tunnel.SetPointer(...) that will run on the remote object.

So I guess that:
class B : MarshallByRef
with that you need only create the object in the domain from class A:
AppDomain domain = ...
B inst = (B) domain.CreateInstanceAndUnwrap(typeof(B).Assembly.FullName, typeof(B).FullName);
inst.DoPlugin("C");
The DoPlugin() method will dynamically load type "C" and call whatever methods are appropriate.

You may have to copy across search paths and evidence when creating "Child" domains (especially for running under unit test libraries):
var dom = AppDomain.CreateDomain("NewDomain",
AppDomain.CurrentDomain.Evidence, AppDomain.CurrentDomain.BaseDirectory,
AppDomain.CurrentDomain.RelativeSearchPath, false);
try
{
var tunnel = (MyMarshallByRef)dom.CreateInstanceAndUnwrap(
typeof(MyMarshallByRef).Assembly.FullName,
typeof(MyMarshallByRef).FullName);
tunnel.DoStuff("data");
}
finally
{
AppDomain.Unload(dom);
}
Also note that any arguments the the DoStuff method, and any types it returns must be marked [Serializable]