That may work; but the problem with that is you're circumventing the ControlPrincipal permission on the CurrentPrincipal property, essentially introducing the possibility that code denied that permission can still change the thread's current principal.
On Tue, 24 Jul 2007 14:56:47 +0200, Ryan Heath <[EMAIL PROTECTED]> wrote: >http://msdn2.microsoft.com/en- us/library/system.threading.executioncontext.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. =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
