Dominik, I have to extend my thanks. Your message that the call to ClearCachedData() made your log4net work with the new time setting made me take another look at the code we have. I made a tiny change and now things are working the way I expected - the log4net times do change when our time change event is detected. I think that the function call wasn't getting executed in the thread where the log4net stuff was being called, and now it explicitly is getting called. And working.
So thanks for chasing this a bit and getting me to take another look at what I thought was working code. Problem solved (that wasn't a log4net problem after all). Much appreciated! On Thu, May 23, 2013 at 9:28 AM, Dominik Psenner <dpsen...@gmail.com> wrote: > As a matter of fact, adding the ClearCachedData() fixed also log4net in my > case. But as mentioned there is that little gotcha of thread-static > variables and that's something that is baked into the CLR. > > Given now a quick outlining of your use case I would solve the problem > like this: > > * make up an installer that can be fired up and sets up things as needed > * make sure the installer launches the installed process > * create an image of the windows embedded OS together with an installer in > the autostart > * ship that image > > This way the installer gets fired up, sets up things as needed and starts > the application once he is done with all the work. The application will > find the system settings as they are needed and all is fine. Of course > there remains the little gotcha that someone can in fact change the > timezone later, but as a matter of fact I would cope with that case either > in the FAQ or with a background thread that restarts the application. > > Cheers > > > 2013/5/23 Warrick Wilson <guywithd...@gmail.com> > >> On Thu, May 23, 2013 at 2:31 AM, Dominik Psenner <dpsen...@gmail.com>wrote: >> >>> >>> I’m wondering, how often does your deployment computer travel from one >>> timezone to another while it is powered on? >>> >> >> Daily, but not in the way you think. The code runs on a device using >> Windows Embedded 7. The device is imaged at our site with OS and our code. >> Then it gets shipped to the customer site, connected to a network and fired >> up. Installer enters one identifying key and our backend server then >> configures the device over the network. We're trying to avoid a reboot >> after initial configuration if possible. >> >> I appreciate your recreation. Our system is indeed multi-threaded, and >> EACH of our threads has a handler that does the ClearCachedData() call. >> Time that our threads generate adjust appropriately. Log4net, as you >> discovered, does not. You're now at the point where I am - aware that the >> library doesn't seem to have a way to force this to change. >> >> If DOES change on a restart - we're trying to avoid that. It's an >> inconvenience. Not surprisingly, a lot of our initial support issues are >> related to installation and first start. The weird times make it awkward. >> So we do log that we changed the time and what the new offset is. I was >> just hoping this wasn't a new issue and someone more familiar with log4net >> would say "oh, that..." and forward a message from 2008 that had a magic >> incantation that would have the same effect as ClearCachedData(). >> >> Thanks for looking into this. >> > > > > -- > Dominik Psenner > ## OpenPGP Key Signature ################################# > # Key ID: B469318C # > # Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C # > ########################################################## > >
