Thanks for the reply, I think you might be right, although I'm still a bit confused:
> The bgw and control.invoke need marshalling. I thought Control.Invoke took care of marshalling? Looking at the Reflector disassembly for Control.Invoke, it seems to call MarshaledInvoke (which at least by name implies some kind of marshalling). Now that I'm looking at it, it also seems to do an ExecutionContext.Capture, which I suspect is actually the ExecutionContext of the calling thread, i.e. my bgw thread. This might also be why it's resetting the context when it's finished. > Reflector also showed ExecutionContext is responsible for undoing/resetting the CurrentPrincipal value. Yes, I agree. The question is - once we are executing from the UI thread, the ExecutionContext should be that of the UI thread, and as a result not be reset when the background thread terminates, or am I wrong? I think that Control.Invoke might be faking the context of the calling thread (as above), so that would explain why my logic is wrong. > An other solution might be, create a custom principal which delegates its calls to an inner principal, say ProxyPrincipal with a property RealPrincipal. > Before executing BWG set the current principal to an instance of ProxyPrincipal and assign RealPrincipal to the Thread.CurrentPrincipal. > Now in the Completed event of the BWG set the RealPrincipal to your newly begotton MyPrincipal instead of the Thread.CurrentPrincipal. >I believe now we have tricked the ExectionContext undo, since the reference to ProxyPrincipal has not been changed. I'll try this if I have a bit of spare time, I suspect it will probably work. Thanks for your suggestions! -- Daniel. -----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Ryan Heath Sent: 24 July 2007 02:57 PM To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: Re: [ADVANCED-DOTNET] Strange issue with Thread.CurrentPrincipal and BackgroundWorker / Threads http://msdn2.microsoft.com/en-us/library/system.threading.executionconte xt.aspx mentions: ... Within an application domain, the entire execution context must be transferred whenever a thread is transferred. This situation occurs during ... Windows Forms thread marshaling through the Windows message pump. ... An other solution might be, create a custom principal which delegates its calls to an inner principal, say ProxyPrincipal with a property RealPrincipal. Before executing BWG set the current principal to an instance of ProxyPrincipal and assign RealPrincipal to the Thread.CurrentPrincipal. Now in the Completed event of the BWG set the RealPrincipal to your newly begotton MyPrincipal instead of the Thread.CurrentPrincipal. I believe now we have tricked the ExectionContext undo, since the reference to ProxyPrincipal has not been changed. HTH // Ryan =================================== 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
