2016-06-01 8 views
1

Wir haben eine Anwendung auf Basis von ASP.NET MVC 5.2 und wir verwenden die Lokalisierung mit Ressourcendateien (RESX), Localization.resx, Localization.de-DE.resx, Localization.de-AT.resx, Localization.en-US.resx, Localization.en-GB.resx ... etc etc die produziert Satelliten-Baugruppen.ASP.NET Lokalisierung stoppt nach ca. 60 Minuten

Wir bestimmen die Sprache zuerst durch Cookie und dann als Rückfall durch Browser-Header-Informationen. Funktioniert sehr gut.

protected internal void Application_BeginRequest(object sender, EventArgs e) 
{ 
    HttpCookie cultureCookie = httpRequest.Cookies[CookieName.Culture]; 
    string cultureName; 
    if (cultureCookie != null) 
     cultureName = cultureCookie.Value; 
    else 
    { 
     if (httpRequest.UserLanguages != null && httpRequest.UserLanguages.Length > 0) 
      cultureName = httpRequest.UserLanguages[0]; 
     else 
      cultureName = null; 
    } 

    cultureName = CultureHelper.GetImplementedCulture(cultureName); // returns default on null 

    Thread.CurrentThread.CurrentCulture = new CultureInfo(cultureName); 
    Thread.CurrentThread.CurrentUICulture = Thread.CurrentThread.CurrentCulture; 
} 

Wir haben die Localization.PropertyName direkt in Ansichten verwenden wie

<div class="text-right">@Localization.Header_TopMenu_Service</div> 

Das funktioniert so weit in Ordnung, aber nach etwa 60-80 Minuten haben wir ein Problem auf nur einer Umgebung (produktive): ist die Lokalisierung nicht arbeite mehr. Es wirkt nur diese Texte! Der Thread hat immer noch die richtige Kultur!

Intern arbeiten wir immer noch mit den Thread.CurrentThread.CurrentCulture Werten wie für statische Texte, Berechnungen von Steuern ... und das funktioniert immer noch. So einige Teile der Anwendung sind jetzt in Englisch (statische Zeug und Logik Zeug wie Berechnung der Steuern) und alle Elemente aus der Localization Ressourcen sind in deutscher Sprache (Standard).

Warum kann das passieren?

Wir dachten, es ist etwas mit Bedingungen Rennen, aber wir haben einige Informationen zu dem Ausgang und alles ist in Ordnung eingebettet:

<!-- 
CurrentCulture == 'en-GB' 
CurrentUICulture == 'en-GB' 
ManagedThreadId == '25' 
IsThreadPoolThread == 'True' 
--> 

Auch wenn die Sprache en-GB in dieser Ausgabe ist die Lokalisierung gibt unseren Standard Das ist deutsch.

Wenn wir die Anwendung neu starten oder recyceln, funktioniert die Lokalisierung wieder für 60 Minuten. Wir haben auch versucht, die Sprache über Filter oder im Controller einzustellen: dasselbe Problem.

Was kann der Grund für dieses seltsame Problem sein? Falsche Implementierung? Etwas mit Satellitenbaugruppen? IIS-Problem? Systemkonfiguration?

Da alles gut auf der Teststufe funktioniert und diese Auswirkungen nur auf der Prod (kein neuer Build, nur eine Kopie) auftreten Ich denke, es ist etwas mit dem System.

+0

Haben Sie sich Ihre Protokolle angeschaut? (Windows-Protokolle, Anwendungsprotokoll usw.). Sie geben an, dass es nach 60-80 Minuten nicht mehr funktioniert, aber nach was? der Start der Anwendung? Hast du einen Caching-Mechanismus? –

+0

@CyrilDurand wie beschrieben 60 Minuten nach dem Auftragen (erneut) starten oder recyceln. Kein Caching hier. Wir haben den aktuellen Zeitstempel in die HTML-Ausgabe integriert, um alle Zweifel am Ausgabe-Caching zu beseitigen. – Ben

+0

Ich habe etwas gefunden .. In unserer 'AssemblyInfo.cs' ist die Zeile '[assembly: NeutralResourcesLanguage (" en ")]'. Wir haben keine Sprache 'en', wir haben nur' en-GB' und 'en-US'. Es fehlt auch der 'UltimateResourceFallbackLocation.Satellite', aber wir haben keinen Fallback in unserer Hauptdll. Kann das der Grund sein? – Ben

Antwort

1

Problem ist gelöst.

Es war eine Race-Bedingung, die Localization.Culture (oder in anderen Implementierungen Resources.Culture) global auf eine bestimmte Sprache festgelegt. Das Problem war, dass dies in Webanwendungen null sein sollte. Wenn dies Null ist, verwendet ResourceManager.GetString()Thread.CurrentThread.CurrentUICulture für die Lokalisierung.

Wenn Localization.Culture nicht null ist, kümmert sich der ResourceManager nicht um Thread.CurrentThread.CurrentUICulture.