Marshal, thread, process, main1_whandle, and appdomain

The latest project requires that the server session information be automatically restored after the server is restarted. I thought it was very easy at first. I only needed to save the session List to the file when the service was stopped, and then read it back at startup. That is, session serialization and deserialization. Naturally, the session is saved in the closing event of the Main Window of the server program, and the loadsession is added to the load event. Compilation succeeded, and everything went smoothly. When I end the main window through Windows service, I find that the closing event is not triggered at all. Of course, I don't have to worry about it. I will continue to add the threadexit event of application to the window to hook up. Still useless. Very strange. Open the source code of the service. In onstop, process. Kill was used to forcibly kill the process. Maybe it was because of this that the event could not be triggered. Change to process. closemainwindow method: the problem is more serious, not only does not trigger the event, but also stops the service (the main window program does stop, although very slow, and is killed by the subsequent kill method ). This is annoying. I tracked process. main1_whandle, which turned out to be empty (intper. Zero ). In this case, the handle of the main window is not obtained. Therefore, the subsequent closemainwindow cannot be successful (closemainwindow is to judge whether the handle is empty first, and postmessage to window wm_close if it is not empty ). So why can't I get a window handle? The reason is that when the service loads the Main Window application through process. the run (New Form () Statement appears too late, and process returns without obtaining a window handle. What the process object obtains is only a snapshot of the Process status at that moment. Even if you use process. Refresh to refresh in onstop, it will not help-when the window is hidden, enumwindows cannot list it.

If there is no window, the session cannot be saved in the window event handler. How can this be done. In desperation, we had to use the "Ancient Times" means of inter-process data sharing to share the window handle. Slow down. Since it is. net, why not use the latest and most advanced appdomain? I was shocked and busy using the executeassembly of appdomain (if it is not in the same directory as starting appdomain, you must specify applicationbase in appdomainsetup. Note:Application. startuppath refers to the actual directory of the program to be started, rather than the directory of the program itself, unless it is directly run. Therefore, avoid using application. startuppath as the program's actual directory.) Replaces process. Start. However! The original executeassembly will enter the entry point of the program, and it is on the original thread, so that the original thread will be suspended and cannot continue. No way, you have to manually create a thread to execute this code. In this case, the appdomainunloadedexception exception will be thrown on this thread during appdomain. Unload. Ignore this and the CLR will automatically take over.

After everything is ready, start the service, log on to the client, and restart the service... Depends on, error, view log: Session serialization error, huh? What does this mean? Masaka .... I suddenly thought that a member in the session is a remote proxy .. Is that true ?? I immediately realized how stupid simple serialization is. What should objref do if marshalbyrefobject is so easy to serialize. So. Similarly, when saving the session, the remote proxy marshal is serialized as objref... OK. Note that during serialization, objref records the object type as the actual type in the file, so unmarshal is not required during deserialization, directly forcibly convert to the corresponding type.

Start the service again, run the client, restart the service, and then operate the client .... Long live, everything is normal!