FirstWeekOfYear ohne getLocaleInfo

Manchmal kommt es vor, dass die Funktion WinAPI::getLocaleInfo() beim Aufruf der Windowsfunktion GetLocaleInfoW in Kernel32 einen Fehler verursacht.

Während die Funktion über den GUI-Client einwandfrei funktioniert, erhält man beim Aufruf über das Enterpriseportal eine Ausnahme:

Dynamics Object Adapter Call failed.

Funktion 'GetLocaleInfoW' in DLL-Bibliothek 'KERNEL32' hat eine Ausnahmebedingung ausgelöst.

Microsoft.Dynamics.BusinessConnectorNet.XppException
at Microsoft.Dynamics.BusinessConnectorNet.AxaptaObject.Call(String methodName, Object[] paramList)
at Microsoft.Dynamics.Framework.BusinessConnector.Session.DynamicsObjectAdapter.Call(String methodName, Object param1)

Für den Benutzer bedeutete dies, dass er in Lookupfenstern zum Auswählen eines Datums schlichtweg einfach nur eine weisse Seite sah, statt des erwarteten Kalenders.*

Leider konnten wir die Ursache des Fehlers nicht herausfinden. Ich vermute allerdings, dass die Kombination von x64-Architektur, dem .NET-Business-Connector und dem Aufruf einer Unicode-Windows-Kernelfunktion etwas damit zu tun hat.

Als Abhilfe haben wir die betreffende Methode Global::firstWeekOfYear(), welche in unserem Fall die Aufrufende Methode war, wie folgt angepasst:

Original:

static int firstWeekOfYear()
{
    #WinAPI
    return str2int(WinAPI::getLocaleInfo(#LOCALE_USER_DEFAULT, #LOCALE_FIRSTWEEKOFYEAR));
}

Modifiziert:

static int firstWeekOfYear()
{
    /* #WinAPI
    return str2int(WinAPI::getLocaleInfo(#LOCALE_USER_DEFAULT, #LOCALE_FIRSTWEEKOFYEAR));
    */

    System.Globalization.DateTimeFormatInfo info = System.Globalization.DateTimeFormatInfo::get_CurrentInfo();
    System.Globalization.CalendarWeekRule rule = info.get_CalendarWeekRule();
    ;
    return(CLRInterop::getAnyTypeForObject(rule));
}

Auf diese Weise wird die Windowsfunktion GetLocaleInfoW in Kernel32 erst gar nicht direkt verwendet.

* Webframework basierend auf Webforms (bis AX 2009)