AppDomains ("application domains")

RE: AppDomains ("application domains")

Ricky Datta — Mon, 02 Jun 2003 08:04:00 GMT

Asynchronous I/O ----------------------------- Can you please talk about how .NET framework takes advantage of I/O completion port [or not ] mechanism on Windows ? I am specially interested in high capacity server implementations. In particular, I want to know about equivalent Win32 mechanisms for AcceptEx, ConnectEx and TransmitPackets (with TF_REUSE flags). Also, How come DACLs and security tokens are not modelled in the .NET framework ? Thanks Ricky

RE: AppDomains ("application domains")

John Lewicki — Mon, 02 Jun 2003 18:43:00 GMT

Could you maybe clarify what you mean by Marshal-By-Bleed? I suspect the meaning is supposed to be self-evident by the use of the word bleed, but there was a conspicuous lack of cartoon light bulbs above my head when I read that paragraph... By the way, its not possible for the blog to be too long when then posts have such fabulous technical content and clarity...

RE: AppDomains ("application domains")

Chris Brumme — Mon, 02 Jun 2003 19:31:00 GMT

The use of the word "bleed" is supposed to imply that the objects bleed across the AppDomain boundary, rather than being properly contained inside the AppDomain they were created in. This is similar to the way colors might bleed from one garment to another in the laundry, though I don't have much direct experience with washing clothes. The effect is that you can have direct references to the same object instance in many AppDomains simultaneously.

RE: AppDomains ("application domains")

Chris Brumme — Wed, 04 Jun 2003 19:55:00 GMT

Ricky, The DACLs and security tokens are not yet modeled in the .NET framework, only because we didn't get around to it yet. I'm sure you will see support for them at some point. As for IOCompletionPort support, have a look at ThreadPool.BindHandle which allows you to associate a handle (like a file handle) with the IOCompletion port that the ThreadPool controls. Also have a look at the System.Threading.Overlapped class, which allows you to receive callbacks via that IOCompletionPort, for any overlapped operations against that handle. I think you are asking whether the FX classes for e.g. Sockets are using this mechanism. That's a better question for the authors of the appropriate FX classes. (I suspect they are using this mechanism).

RE: AppDomains ("application domains")

pedronis — Mon, 09 Jun 2003 18:40:00 GMT

Having a kind of in-memory created (dynamic) assemblies that are implicitly "unloaded" when they and their types are no longer reacheable would be a nice feature. Many dynamic languages impl. over the JVM depends on class unloading through GC (there is based on classloaders/their classes unreachability). I think , because of type identity rules and only-once guarantees for static initializers, this can be done only for some kind of only in-memory created assemblies. At the moment in-memory created assemblies are not GCed indipendently of the AppDomain. right? e.g. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpcondetailsofregularexpressionbehavior.asp regards.

RE: AppDomains ("application domains")

Cosmo — Mon, 16 Jun 2003 08:26:00 GMT

These weblogs are among the very few that I've found that are actually worth reading. Thanks, Chris. Keep up the great work (and plug those Framework holes!) Cosmo

RE: AppDomains ("application domains")

Chris Brumme — Mon, 23 Jun 2003 19:57:00 GMT

Pedronis, Everyone asks us for automatic implicit unloading of assemblies based on reachability. It's a feature that is extremely popular, but very expensive for us to build. The decision of when/if to deliver this feature is more of a scheduling exercise. Other features keep getting in the way.

RE: AppDomains ("application domains")

Matt Fausey — Tue, 22 Jul 2003 00:50:00 GMT

Chris, I've been plagued with an "Attempted to access an unloaded AppDomain" for several months now. We have a .NET Email Component such that for some ASP.NET customers that user our DLL will get this error occasionally. Our DLL is strongly named, so I am confused as to how this could be happening. It is a mixed-mode DLL implemented in managed C++ such that a thin managed C++ wrapper surrounds the unmanaged C++ implementation. I've gone over every piece of documentation and information on the Net that I can find about creating managed wrappers around unmanaged types, and as far as I can see I am doing everything correctly. To give you a flavor of what happens, here is an example snippet of a customer's code: Chilkat.Email email = new Chilkat.Email(); email.From = FromAddress; email.AddTo("", Address); email.Subject = Subject; email.Body = Body; The exception occurs when I set a value to the Body. The other statements execute without issue. Also, when I dump "email" in the Command Window, I get this: {Chilkat.Email} System.Object: {Chilkat.Email} Body: <error: an exception of type: {System.AppDomainUnloadedException} occurred> Decrypted: false EmailDate: {7/9/2003} EncryptedBy: "" FileDistList: "" From: "" FromAddress: "" FromName: "" HtmlCharset: "us-ascii" LastError: "" LocalDate: {7/9/2003} m_email: 84812680 Mailer: "Chilkat Software Inc (http://www.chilkatsoft.com)" NumAlternatives: 0 NumAttachedMessages: 0 NumAttachments: 0 NumBcc: 0 NumCC: 0 NumRelatedItems: 0 NumReplacePatterns: 0 NumTo: 0 OutlookDistList: "" PlainTextCharset: "us-ascii" RawHeader: "MIME-Version: 1.0\r\nDate: Wed, 09 Jul 2003 10:55:07 -0400\r\nMessage-ID: <CHILKAT-MID-b18bc301-2589-4599-be87-d83d647ca053@blah>\r\nContent-Type: text/plain; charset=\"us-ascii\"\r\nContent-Transfer-Encoding: 7bit\r\nX-Mailer: Chilkat Software Inc (http://www.chilkatsoft.com)\r\nX-Priority: 3 (Normal)" ReceivedEncrypted: false ReceivedSigned: false ReplyTo: "" ReturnReceipt: false SendEncrypted: false SendSigned: false SignaturesValid: false SignedBy: "" Size: <error: an exception of type: {System.AppDomainUnloadedException} occurred> Subject: "" Uidl: "" Note that Size and Body both return exceptions. Can you think of anything that could possibly cause this? Any help would be much appreciated. Best Regards, Matt Fausey Chilkat Software, Inc.

RE: AppDomains ("application domains")

Chris Brumme — Sat, 26 Jul 2003 05:39:00 GMT

Matt, Feel free to contact me directly on this matter (if you can decode the mangling of my Microsoft email alias!). My first question is whether you built this for V1 or V1.1 of the CLR. If you built it for V1 and you are using MC++ with ASP.NET, then there's a high likelihood that I know the problem. If you built it with V1.1, it depends what compiler switches you used. Let's resolve the issue off-line from this blog, and then I can post the resolution back here -- for anyone else with this problem -- if it's what I suspect. The problem seems to be mentioned at http://support.microsoft.com/default.aspx?scid=kb;en-us;309694. However, I don't see an updated article with the 1.1 solution which is more palatable than the one described in the 309694 knowledge base article. Starting with 1.1, there's a Managed C++ compiler switch that allows you to control this situation.

RE: AppDomains ("application domains")

Rocco — Tue, 06 Jan 2004 17:41:00 GMT

Chris, What is the Managed C++ compiler switch? Rocco

AppDomains (

A Blog for Graymad — Wed, 14 Jan 2004 07:45:00 GMT

AppDomains (

A Blog for Graymad — Wed, 14 Jan 2004 08:27:00 GMT

re: AppDomains ("application domains")

Kent Brown — Fri, 13 Feb 2004 05:05:00 GMT

I am having trouble Unloading an AppDomain that has been set up to host remoting. It give the thread cannot be unwound exception. WHat can I do to make sure it unloads?

re: AppDomains ("application domains")

Chris Brumme — Fri, 13 Feb 2004 19:42:00 GMT

Rocco, the managed C++ compiler switch is /clr:initialAppDomain.

re: AppDomains ("application domains")

Chris Brumme — Fri, 13 Feb 2004 19:45:00 GMT

Kent, the first thing you should do is get a stack trace of the "reluctant" thread. Most likely it is performing unmanaged blocking rather than managed blocking. Less likely, it is executing CPU-intensive unmanaged code. In either case, the CLR cannot safely take control of the thread. If it is performing unmanaged blocking, consider switching it over to managed blocking instead. (See my post on Managed Blocking, or the most recent post on Apartments and Pumping for additional detail).

re: AppDomains ("application domains")

Stuart — Wed, 24 Mar 2004 17:16:00 GMT

I have a question which may betray a fundamental misconception about what AppDomains are supposed to do, or may have a trivially simple answer.

When you talk about domain-neutral assemblies above, you then state that even domain-neutral assemblies need per-AppDomain state for their static variables. You state this as a foregone conclusion.

However, the problem domain that I'm trying to tackle (for which I hope that AppDomains may be the answer) specifically needs all state (including static variables if there are any) in one assembly to be *shared* across all the AppDomains that it loads.

My scenario is sort of like a plugin system: Host application loads several assemblies that it wants to isolate from itself and each other and set limited permissions on, and then runs code inside those assemblies (which implement a predefined interface eg IPlugin that's defined in the host application), passing them objects through which they can manipulate the host environment in certain well-defined ways.

So the host application state is truly global, and when one of the plugins invokes a method which accesses static variables in the host app, it really should be accessing a *single* copy of that static variable, not a separate one per plugin.

Am I trying to abuse AppDomains by wanting to do this, or is it a valid use of them, and if so, what would I need to do in the host application to get the semantics I want?

(Currently, my code ignores the isolation and security issues and just does the following (apologies for syntax problems, I'm typing this from memory), which are the semantics I'm trying to preserve:

Assembly asm = Assembly.LoadFrom(path);
// get some custom attributes on the assembly to find the name of a type that implements IPlugin
Type type = asm.GetType(typeName);
ConstructorInfo cons = type.GetConstructor(new Type[] {})
IPlugin plugin = (IPlugin) cons.Invoke(new object[] {});
plugin.PluginMethod(pluginAPIObject);

)

re: AppDomains ("application domains")

Martin — Thu, 25 Mar 2004 16:14:00 GMT

Hi guys. Since you seem to know so much about appdomains, maybe you could find the time to help me out here. See, I have a windows service that keeps calling a web service. Problem is, after a while (12-13 hours) I get this error "AppdomainUnloadedException" apparently in the middle of the processing of the data by the web service. Until that happens the calls to the web service have executed in the same iis session.
Is there some web.config or iis setting that eludes me or can I stop this by catching this exception in global.asax? The application in the iis does not exit.
I add the call stack for whatever good it will do:

[AppDomainUnloadedException]: Attempted to access an unloaded AppDomain.
at System.Threading.Thread.SetCompressedStackInternal(IntPtr unmanagedCompressedStack)
at System.Threading.Thread.SetCompressedStack(CompressedStack stack)
at System.Xml.XmlTextReader.CreateScanner()
at System.Xml.XmlTextReader.Init()
at System.Xml.XmlTextReader.Read()
at System.Xml.XmlReader.MoveToContent()
at System.Web.Configuration.XmlUtil.OpenXmlTextReader()
at System.Web.Configuration.HttpConfigurationRecord..ctor(String filename, HttpConfigurationRecord parent, Boolean inheritable, String path)
[ConfigurationException]: The XML file c:\winnt\microsoft.net\framework\v1.1.4322\Config\machine.config could not be loaded. Attempted to access an unloaded AppDomain. (c:\winnt\microsoft.net\framework\v1.1.4322\Config\machine.config)
at System.Web.Configuration.HttpConfigurationSystem.CacheLookup(String vpath)
at System.Web.Configuration.HttpConfigurationSystem.ComposeConfig(String reqPath, IHttpMapPath configmap)
at System.Web.HttpContext.GetCompleteConfigRecord(String reqpath, IHttpMapPath configmap)
at System.Web.HttpContext.GetCompleteConfig(String path)
at System.Web.HttpContext.GetAppLKGConfig(String name)
-->
--.
at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream)
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
at mywindowsservice.myWebService.datapush.readXmlBytes(Byte[] data, String parameter)

Any suggestions will be appreciated.
/Martin

re: AppDomains ("application domains")

Chris Brumme — Fri, 26 Mar 2004 01:59:00 GMT

Stuart,

The vast majority of static fields are cloned for each AppDomain. A few others are cloned for each thread for each AppDomain or for each Context for each AppDomain. In other words, they are scoped at an even finer granularity than per AppDomain. We also support RVA-based static fields, which are process global. However, such statics can only contain primitive values. This is to avoid the potential of bleeding instances across an AppDomain boundary, but they may be sufficient for your needs. (All of the above is in my very first blog, entitled "Static Fields").

Any objects must be marshaled somehow across the AppDomain boundary. This is intentional. Think of this like the address space separation of unmanaged processes. Our equivalent of memory mapping could be considered either agile objects or RVA-based statics.

re: AppDomains ("application domains")

Chris Brumme — Fri, 26 Mar 2004 02:02:00 GMT

Martin,

It sounds like you might be running in ASP.NET. If this is the case, then ASP.NET will unload AppDomains for a variety of reasons. This includes changes to the application running in the AppDomain (they use file change notifications to monitor your aspx files, config files, etc.), and it includes high resource usage. I don't know whether there are other circumstances that cause this -- like perhaps they age out old applications after a long period of inactivity.

If you are not running in ASP.NET and you don't believe AppDomains should be unloaded, I would recommend setting a breakpoint on AppDomain.Unload and see who the caller is.

re: AppDomains ("application domains")

Martin — Fri, 26 Mar 2004 10:16:00 GMT

Chris:
Yes, I'm running this in asp.net. I think I'll take your advice and check out the unload method to try to find out if I can stop it from unloading. A posting on another site suggested I look at the asp(x) script timeout, maybe I hadn't set it high enough after all. Thanks for your help.
/Martin

re: IServiceProvider and Plugin Architecture

Something Clever — Sun, 09 May 2004 06:29:00 GMT

re: AppDomains ("application domains")

Mark Traudt — Wed, 26 May 2004 15:01:00 GMT

In reference to:

There’s so much more I had intended to write about. For example, some ambiguities exist when unmanaged (process-wide) code calls into Managed C++ and has to select a target AppDomain. This can be controlled by flags in the VTFixup entries that are used by the IJW thunks.

This is a topic I am trying to get a better understanding of. We are having problems with a Managed C++ DLL that has a non-default appdomain and does LOTS of unmanaged calls (both P/Invoke and COM Interop). Also, the managed code is frequently called back by the unmanaged code.

The code is compiled using VS .NET 2003 and we are running on 1.1 of the CLR. Interestingly, using the "initialAppDomain" flag SEEMS to make the problem go away, but we do not want to use this flag since we support unloading our app domain.

On www.msdnaa.net, they say that:

With version 1.1 of the .NET Framework, the vtable includes a flag that indicates to the runtime that if the call comes into the assembly from native code, the application domain that's used will be that of the last application domain used to call into native code.

But won't this cause problems if you have managed/unmanaged transitions from multiple domains? What if I just called into unmanaged code from Domain A, and then receive a callback that really should be directed to Domain B? How can you ever reliably receive callbacks if you call unmanaged code from multiple domains?

re: AppDomains ("application domains")

Mark Traudt — Thu, 27 May 2004 02:20:00 GMT

Well, through lots of experimentation we were able to fully understand the behavior with and without the "/clr:initialAppDomain" flag.

This is a topic that needs more detailed documentation from Microsoft, so that others don't go through what we went through.

For example, the docs seem to imply that the only reason you would use this flag is if you want to run on CLR 1.0. However, there are some cases where the 1.0 behavior makes more sense.

Also, on MSDNAA they describe the 1.0 behavior as:

"In the first version of the Framework, the runtime was consistent and ensured that the callback into managed code would go to the first application domain."

I originally took "first application domain" to mean the first app domain loaded into the runtime. However, I think they really mean "the first application domain this assembly is loaded into". Is that correct?

re: AppDomains ("application domains")

Lyon — Thu, 10 Jun 2004 14:15:00 GMT

Chris:

I am new to AppDomains and do not quite understand "a given thread is not confined to a single application domain", also "multiple disjoint regions of stack" and how threads "stack in".
Could you please further explain or advise where I can get more detail.

thank you

re: AppDomains ("application domains")

Lyon — Thu, 10 Jun 2004 14:15:00 GMT

re: AppDomains ("application domains")

Chris Brumme — Thu, 01 Jul 2004 17:56:00 GMT

Mark,

You are correct that 'initialAppDomain' means the first AppDomain that the assembly is loaded into, rather than the first AppDomain of the process. And I agree with you that there are scenarios where initialAppDomain is preferred -- though this position has been disputed by some of the folks over here.

I think you will probably see some improvements in this area in Whidbey (hopefully with some documentation improvements, too). However, I don't think those improvements made the first Whidbey Beta.

re: AppDomains ("application domains")

Chris Brumme — Thu, 01 Jul 2004 18:11:00 GMT

Lyon,

AppDomains are boundaries around groups of objects within a process. Threads live within a process, rather than within any one of these AppDomain boundaries. When a thread calls from one AppDomain to another, it passes through the boundary and leaves a special marker frame on the stack. When the thread returns from the second AppDomain, the marker frame is popped off the stack during the reverse transition.

If you look at the stack of a thread, you can imagine segments of stack separated by the marker frames. These segments between the marker frames are what I meant by "multiple disjoint regions of stack."

re: AppDomains ("application domains")

MIGUELÓN — Mon, 12 Jul 2004 11:04:00 GMT

Hi,

I'm newbie in this tasks related to application domains and I would like a rapid and a simple advice for using them correctly:

1. Should I manage myself application domains, or should I let the CLR manage them? In what cases does this personal management deserve? Does alter performance of the application?

2. Does CLR perform a good management of applicacion domains by default, without managing nothing myself?

3. By default, a .NET application (Winforms, ASP.NET, etc.) maps to one (and only one) application domain? 1 process --> 1 application domain --> a .NET application?.

re: AppDomains ("application domains")

Chris Brumme — Mon, 12 Jul 2004 16:23:00 GMT

The CLR (meaning the runtime engine) doesn't manage application domains itself. Instead, the application or some application framework is responsible for creating them, executing code in them, and destroying them.

In the case of ASP.NET, this is handled by the application framework. It does a great job and there is no reason for you to interfere.

In the case of WinForms, a WinForms app typically has a single application domain. For most GUI applications, this is appropriate. If you have an add-in model based on WinForms where it makes sense to use different AppDomains for each add-in (for all the usual reasons like isolation of binding, ability to unload, ability to have a distinct security policy, etc.) then your add-in model should create and manage the appdomains.

re: Whidbey breaking change --- Caching binding failures

Junfeng Zhang's .Net Framework Notes — Thu, 22 Jul 2004 20:47:00 GMT

re: AppDomains ("application domains")

dianyingxiazai — Mon, 02 Aug 2004 09:28:00 GMT

[href=//www.dmoz.net.cn/ title="wangzhidaquang"]
[href=//www.86dmoz.com/ title="jingpingwangzhi"]
[href=//www.kamun.com/ title="mianfeidianying"]
[href=//www.kamun.com/ title="dianyingxiazai"]
[href=//www.kamun.com/ title="MP3 free download"]
[href=//www.pc530.net/ title="diannaoaihaozhe"]
[href=//www.5icc.com/ title="duangxingcaixingxiazha"]
[href=//www.dianyingxiazai.com/ title="dianyingxiazai"]
[href=//www.yinyuexiazai.com/ title="yinyuexiazai"]

Domain Neutral Assemblies

Junfeng Zhang's .Net Framework Notes — Thu, 05 Aug 2004 02:40:00 GMT

Failures in AppDomain.Unload

manish godse's remoting blog — Mon, 01 Nov 2004 20:22:00 GMT

Immutable arrays as value objects

Hackward and Foreword — Sat, 16 Apr 2005 19:06:17 GMT

Immutable arrays as value objects

Hackward and Foreword — Wed, 11 May 2005 04:50:51 GMT

Special threads in CLR

Yun Jin's WebLog — Tue, 12 Jul 2005 21:32:23 GMT

Question: How many threads does a typical managed process have when it just starts to run?&nbsp;&nbsp;...

Closing Documents Programmatically is not simple

Misha Shneerson — Mon, 25 Jul 2005 07:22:39 GMT

Both Word and Excel OMs have APIs that allow closing documents programmatically. I suppose there are...

How many threads does a typical managed process have when it just starts to run?

C#, VS Deployment and all geek talk — Thu, 18 Aug 2005 19:33:11 GMT

Special threads in CLR

Yun Jin's WebLog — Sun, 28 Aug 2005 22:44:57 GMT

Question: How many threads does a typical managed process have when it just starts to run?&nbsp;&nbsp;...

Closing Documents Programmatically is not simple

Misha Shneerson — Sun, 18 Sep 2005 09:54:06 GMT

Both Word and Excel OMs have APIs that allow closing documents programmatically. I suppose there are...

Creating and Working with Applications in AppDomains

Infosys | Microsoft — Thu, 05 Jul 2007 14:34:41 GMT

How to create and work with applications in AppDomains

Cross-AppDomain Workflow Local Services

All Your Base Are Belong To Us — Wed, 06 Feb 2008 21:03:31 GMT

I stumbled across an interesting issue today that I thought might be worth sharing.  The design

Web Garden, AppDomain, statics… when Sql Server is not enough to save your session

A developer's strayings — Sun, 30 Mar 2008 23:34:15 GMT

Things have gone a bit crazy lately, we’ve been under a huge workload and the time left for blogging

Using Overlapped I/O from Managed Code

beefycode.com — Sat, 26 Jul 2008 20:20:50 GMT

Using Overlapped I/O from Managed Code

Bad Locking Patterns

Programming tidbits: store & retrieve — Mon, 28 Jul 2008 20:40:09 GMT

Multithreading adds the overhead of making sure data is accessed in a thread safe way. Win32 API uses

kevin Mocha - More about app domain

kevin Mocha - More about app domain — Wed, 17 Sep 2008 21:33:40 GMT

PingBack from http://blog.lulutech.com/PermaLink,guid,5666c934-98e2-4433-90c1-d09d6cc4d55a.aspx

cbrumme s WebLog AppDomains application domains | Insomnia Cure

cbrumme s WebLog AppDomains application domains | Insomnia Cure — Tue, 09 Jun 2009 01:18:45 GMT

PingBack from http://insomniacuresite.info/story.php?id=3323

cbrumme s WebLog AppDomains application domains | Cellulite Creams

cbrumme s WebLog AppDomains application domains | Cellulite Creams — Tue, 09 Jun 2009 06:11:10 GMT

PingBack from http://cellulitecreamsite.info/story.php?id=756

cbrumme s WebLog AppDomains application domains | home lighting

cbrumme s WebLog AppDomains application domains | home lighting — Sun, 14 Jun 2009 05:02:35 GMT

PingBack from http://homelightingconcept.info/story.php?id=2148

cbrumme s WebLog AppDomains application domains | fix my credit

cbrumme s WebLog AppDomains application domains | fix my credit — Wed, 17 Jun 2009 05:16:41 GMT

PingBack from http://fixmycrediteasily.info/story.php?id=975