Hello, I just had a quick question.
In the ApplicationEvents class of my winforms application, we need to see if a user has the correct permissions, if not, if the user is a special kind of user, we prompt them and ask if they would like to reset their permssions. If yes, I use Application.Restart to restart the applicaiton. However, when I do this, it seems like CSLA.ApplicationContext.User has not reset or has some old values when the appliation resets as menu options are still disabled based on the IsRole Function. The application has to be stopped completely and restarted before the changes to the CSLA.ApplicationContext.User can be seen.
Any ideas?
Environment = WinForms
Version = CSLA.Net 2
Language = VB.Net 2.0
That can be a difficult problem to solve.
In a WinForms app, ApplicationContext.User comes directly from System.Threading.Thread.CurrentPrincipal.
.NET has rules around how and when CurrentPrincipal can be changed, and how it is set on new background threads, etc. It has been a long time since I used all those features, but there are methods attached to the current Thread and AppDomain objects that control these principal policies.
In any case, it is probable that Application.Restart does nothing to Thread.CurrentPrincipal. The Application object is part of WinForms, and the Thread object is part of .NET in general. So it is probably up to you to directly manage or reset ApplicationContext.User based on your application requirements.
Rocky, thanks for the reply. It dosen't seem like a CSLA problem.
It seems to have something to do with MDI Form.
When stepping through the code, I do Application.Restart on a child form, the Application restarts as expected, however the code on the MDI Parent Form that disables/enables menu items doesn't even get called. Even the MDI Parent Form's constructor doesn't get called.
It is almost like everything is still in memory and the application just restarts.
I'm thinking it's more of a side-effect of the way MS coded the Application.Restart() method. The help files talk about using "the same context", and when you look at the code, under certain situations it looks like the AppDomain is essentially re-used. So depending on how your application is launched, I wouldn't be surprised to see the results you're seeing.
Unfortunately, the only way I know of to be sure about this kind of stuff is to essentially create a separate "launcher app". This disconnects your startup code from your main app, thus obviating the need for the restart - or making it much easier/cleaner through a Process.Start() call. The problem is that changes your app deployment, and I'm guessing we're talking about an already-in-production app, so pushing a new app down to your clients (and updating all the various shortcuts that may be in place) can be problematic.
- Scott
Copyright (c) Marimer LLC