No Windows CE .NET 4.2, por força SetTimeZoneInfo jeito?

Question

Nosso produto contém um sistema de task-manager que permite que aplicativos para executar código em uma DLL em cima de um intervalo programado, especificar as regras sobre se uma falha da tarefa deve desativar o aplicativo relacionado, etc. Na maior parte é usada para dados de upload, dados de download, a manutenção de banco de dados local, etc. Uma das funções utilizadas é para sincronizar o tempo dispositivos via NTP e definir o oS' info fuso horário. Para isso, usamos classe DateTimeHelper de OpenNetCF, que parece servir como um invólucro em torno Win32 P / Invoca.

Uma das outras características do gerenciador de tarefas é que se uma tarefa é executada mais do que a sua janela de tempo, o gerenciador de tarefas irá Thread.Abort () para permitir que outras tarefas para executar. Estamos vendo um número alarmante de abortos de rosca em que a maior função na pilha é OpenNetCF.WindowsCE.NativeMethods.SetTimeZoneInformation (). Por que o P subjacente / Invoke (SetTimeZoneInfo) pendurar por um longo tempo?

Nosso código é executado no Windows CE 4.2, e com uma base de usuários muito menor, no Windows CE 5.0 - o código aqui é a mesma entre as duas versões. Até agora, eu já vi isso ocorrer em 4,2 dispositivos, mas nunca em 5.0, e mesmo com o menor número de usuários em 5.0, eu acho que eu teria visto se tivesse sido ali presentes.

A função abaixo é a função a partir da qual o problema deriva. Ele converte uma zona abreviatura tempo para seu nome completo, em seguida, usa o nome para encontrar o fuso horário certo e tentativas para definir fuso horário atual do dispositivo para que um.

        public static bool SetTimeZone(string timeZoneAbbreviation)
        {
            string TimeZoneInfo = string.Empty;
            bool timeZoneChanged = false;

            switch (timeZoneAbbreviation)
            {
                case ALASKA:
                    TimeZoneInfo = ALASKA_TZN;
                    break;
                case ALASKA_ALT:
                    TimeZoneInfo = ALASKA_TZN;
                    break;
                case ATLANTIC:
                    TimeZoneInfo = ATLANTIC_TZN;
                    break;
                case ATLANTIC_ALT:
                    TimeZoneInfo = ATLANTIC_TZN;
                    break;
                case CENTRAL:
                    TimeZoneInfo = CENTRAL_TZN;
                    break;
                case CENTRAL_ALT:
                    TimeZoneInfo = CENTRAL_TZN;
                    break;
                case EASTERN:
                    TimeZoneInfo = EASTERN_TZN;
                    break;
                case INDIANA:
                    TimeZoneInfo = INDIANA_TZN;
                    break;
                case HAWAII:
                    TimeZoneInfo = HAWAII_TZN;
                    break;
                case MOUNTAIN:
                    TimeZoneInfo = MOUNTAIN_TZN;
                    break;
                case ARIZONA:
                    TimeZoneInfo = ARIZONA_TZN;
                    break;
                case PACIFIC:
                    TimeZoneInfo = PACIFIC_TZN;
                    break;
                case PACIFIC_ALT:
                    TimeZoneInfo = PACIFIC_TZN;
                    break;

                default:                    
                    break;
            }

            TimeZoneInfo += "\0";

            TimeZoneCollection tzc = new TimeZoneCollection();
            tzc.Initialize();

            foreach (TimeZoneInformation tzi in tzc)
            {
                string tzDisplayName = tzi.DisplayName.TrimEnd(new char[]{'\\','0'});

                if (tzDisplayName.ToUpper(CultureInfo.CurrentCulture).Equals(TimeZoneInfo.ToUpper(CultureInfo.CurrentCulture)))
                {
                    DateTimeHelper.SetTimeZoneInformation(tzi);
                    System.Globalization.CultureInfo.CurrentCulture.ClearCachedData();
                    timeZoneChanged = true;
                    break;
                }
            }

            return timeZoneChanged;
        }

Graças como sempre por sua ajuda. Quaisquer pensamentos?

Answer 1

A chamada DateTimeHelper.SetTimeZoneInformation é um wrapper muito fina em torno de um P / Invoke para o SetTimezoneInformation API (Eu apenas verificado que na fonte). Ele basicamente faz a chamada e verifica o código de retorno -. Nada mais, de modo que regras muito bonitas fora do próprio SDF como a causa raiz

Em seguida, olhando para o MSDN doc para SetTimezoneInformation , é uma chamada síncrona realmente simples que retorna verdadeiro ou falso. Isso me diz que a API não é provável que a causa raiz também.

Uma coisa a lembrar-se é na CE é que você pode não assumir a plataforma é impecável becasue é feito pelo OEM e, portanto, pode ter variações. O fato de que você vê o fracasso em 4.2 e não 5.0 me levaria para verificar o seguinte:

1. Verifique se a imagem 4.2 dispositivo tem todos os QFEs aplicado
2. ver se há uma diferença código OS entre 4,2 e 5,0 para o material fuso horário (Eu duvido, mas eu não tenho PB 4.2 instalado por mais tempo).
3. Verifique a implementação OEM para definir o tempo. Alterar o fuso faz implicitamente uma chamada para definir a hora e é possível que há um bug no BSP 4.2 que tem um bloqueio potencial ou raça que você está batendo.