CreateInstanceAndUnwrap - What Next?

  • Thread starter Thread starter localhost
  • Start date Start date
L

localhost

From a console app, I have created a seperate AppDomain with
"CreateInstanceAndUnwrap" and placed object instances inside it.

Now in a seperate class, instanced by the console app, I want to get
at the instance inside the AppDomain and execute a method.

How do I do that?

Thanks.
 
When you call CreateInstanceAndUnwrap on an AppDomain, you create an
instance within this AppDomain. Apparently the call is made from another
AppDomain, and the calling code in that domain is returned a marshaled
reference to the instance created. You can cast the returned reference to
the type of the created object instance and use it as it was a real
reference. Bear in mind though that the object whose instance is being
created should inherit from MarshalByRefObject.

You can also marshal objects by value but this, in general, is more
appropriate for value types and data holder objects.
 
I am not 100% clear on this.

I have ditched CreateInstanceAndUnwrap.

I have an ASP.NET web application with its own AppDomain.
In global.asax Application_Start I create a new AppDomain and have an
ObjectHandle of an instanced class that exists in the assembly in the
new AppDomain.

AppDomain hostedDomain =
AppDomain.CreateDomain( "fastdom" , null , (AppDomainSetup)null );
ObjectHandle hostHandle = hostedDomain.CreateInstance
( "test.fastdom" , "test.fastdom.testclass" );
testclass testthis = (testclass)hostHandle.Unwrap();
// testclass inherits from MarshalByRefObject


Now from any .aspx page (or a class instanced in a page), I need to
get to the instance in that new AppDomain.
Should I store hostHandle in Application Cache?

How do I get to that AppDomain from another web application
(which will naturally have its own AppDomain), or from another
dynamically generated AppDomain created in my main web application?


Thanks.
 
Once you have the handle returned to the initial AppDomain, you should
unwrap it to get a reference to a proxy that will marshal your calls to the
instance created in the secondary domain.
As it follows from your code, you already have this Unwrap() call in place -
so it seems like you can use 'testthis' to access the created instance. You
can store 'testthis' in the Application object to have it accessible from
anywhere in your Web app.

As for your second question, I should give it additional thinking - I cannot
remember how to access an already existing instance in another AppDomain.
 
And to follow up a little more, the dynamically-created AppDomain
(which lives in a seperate assembly in a discrete standalone .dll) is
called from global.asax in an ASP.NET application. But when IIS is
restarted, the appdomain does not go away, so the .dll cannot be
deleted. Is there a finalizer or destructor trick I should do to make
sure the AppDomain closes when everything else does?

Thanks.
 
And to follow up a little more, the dynamically-created AppDomain
(which lives in a seperate assembly in a discrete standalone .dll) is
Click to expand...

AppDomains 'live' in processes, not in .dlls. As long as the hosting process
is alive, so is the AppDomain.
called from global.asax in an ASP.NET application. But when IIS is
restarted, the appdomain does not go away, so the .dll cannot be
deleted.
Click to expand...

Looks like IIS restart does not force the ASP .NET working process to
restart. I am not sure how one could ensure automatic restart though. You
can try configuring your Web application to run within the IIS process, but
again, I am not sure this has effect on ASP .NET - I haven't done ASP .NET
for more than half a year.
 
This link answers many of your appdomain questions.
http://www.gotdotnet.com/team/clr/AppdomainFAQ.aspx

If the appdomain you created is done so within the context of of an ASP.NET
app, and if this app is loaded by IIS, then resetting IIS will unload all
the secondary appdomains running within its worker process. If the DLL is
locked then something else is loading it. There must be something else going
on here.
 
Back
Top