Thanks for all the help so far. To answer some questions:
We are using multi-app domains so that each sub-application has its own context (its own statics / its own app.config ) which allows the apps to behave mostly as if they were stand alone .exes and also discourages coupling between apps because they can no longer use static variables to share state. Our original intent was to only use multi-app domains and a single UI thread, however, WinForms makes assumptions (through the use of statics) that all forms will be in the same AppDomain and thus some things break when you create a form in a second AppDomain (specifically Tabbing). An interesting aside to this is that .net 2.0 is better about this, but it still doesn't have it right (tabbing is now reversed instead of not working at all). This is interesting because microsoft's own VTSA team claims you can run winforms PlugIns in thier own appDomain. I pointed out this problem to them at teched and they seemed unaware of it. They have since confirmed it to be an issue, but I have yet to hear of a resolution. Anyway, to get around the AppDomain problem we have attempted to run each sub-application on its own UI thread within its own AppDomain. As mentioned originally, we've got this working pretty well, except for the debugger issue. We do mark all our threads specifically as STA and we are carefull about invoking correctly for any calls from background threads to our UI threads. At Danny's suggestion, I tried turning off FuncEval, but that does not solve the problem. Thanks for the pointers to Mike Stall's blog. I will try to contact him or one of the bloggers he links to directly to see if they can offer any other advice. -Mike On 7/19/06, Danail Grigorov <[EMAIL PROTECTED]> wrote:
I observed the same behaviour with VS2003. Although I don't know if you've hit the same problem, in our case it, the problem turned out to be the interaction between 'Allow Property evaluation in variables window' (in Options/Debug/General) being turned on, and having a 'watch' on a property of some Control. I guess that forces the debugger to do a FuncEval on the property, from a different thread, which ultimately results in a windows message being sent cross-thread (we had watch on a Control.Text property which resulted in WM_GETTEXT) and this sometimes (because of the window manager's design that only the thread that created the window can process its messages) causes a deadlock -- which eventually forces the debugger to abort the thread the is doing FuncEval on the property - and hence the ThreadAbortException. Also, please mind, that having a watch is not the only way to hit this problem, it can also came from the tooltips that the debugger displays sometimes. As somebody already mentioned this is all explained (very well) in Mike Stall's blog -- especially the entries about FuncEval In short, try to turn off 'Property evaluation' and see if this helps. Danny ----- Original Message ----- From: "Michael Gold" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, July 19, 2006 3:07 AM Subject: [ADVANCED-DOTNET] VS2003 Debugging Issues with Multiple UI Threads > Hello, > > My team has developed an application that uses Multiple AppDomains and > Multiple UI threads to house somewhat related components (or > sub-applications) within a common UI "shell" allowing these components to > communicate in a loosely coupled fashion and all that other good stuff > (its > somewhat CAB like, but we think better). It works great, except we are > running into a problem with the vs2003 debugger where we set a break point > in one of the sub-applications and then close the sub-app (which causes an > Application.Exit in its AppDomain) and then re-open the sub-app (which > creates a new AppDomain and UI Thread). Soon after doing that, when the > break point is hit, the debugger will freeze for 10 seconds and then throw > a > first chance ThreadStopException which will cause the sub-app to crash. > The problem only seems to happen in the debugger and under very limited > testing in vs2005, we don't see the problem (unfortunately we are still > stuck in a 1.1 world for now). > > Has anyone tried anything similar or seen this behavior from the debugger? > I googled for ThreadStopException and found some chatter about the Watch > window causing this, but we still get this problem even if we hide all the > watch/locals/etc windows. > > Thanks in advance for any suggestions. > Mike > > =================================== > This list is hosted by DevelopMentor(r) http://www.develop.com > > View archives and manage your subscription(s) at > http://discuss.develop.com =================================== This list is hosted by DevelopMentor(r) http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
=================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
