Wir haben FSharp.Core.dll als Teil einer Bereitstellung einer Webanwendung auf IIS 8 (ASP.NET Web API) aktualisiert und nach der Bereitstellung sofort FSharp.Core FileLoad-Ausnahmen erkannt. FSharp.Core.dll version ist von 4.3.0.0 nach 4.3.1.0 gegangen.
Bei unserer automatisierten Standardbereitstellung werden die Inhalte des Anwendungsordners durch aktualisierte Binärdateien (dlls), global.asax und web.config ersetzt. Dadurch wird der Apppool von IIS wiederverwendet. FSharp.Core.dll wird als Teil des Builds gebündelt. Unsere Anwendungen werden in einer Umgebung mit Lastenausgleich bereitgestellt. Unsere automatisierten Bereitstellungsskripts verwenden 'robocopy', um das Anwendungsverzeichnis (mywebapp, unten) zu bereinigen und den neuen Inhalt an seine Stelle zu kopieren.
Typische IIS-Anwendungsordnerstruktur:
%Vor%Wir haben festgestellt, dass die Bereitstellung erfolgreich abgeschlossen wird, wenn die Anwendung während der Bereitstellung keine Anforderungen ausgibt. Wenn die Anwendung während der Bereitstellung jedoch Anforderungen für das Laden und Bereitstellen erfüllt, gibt die Anwendung eine Ausnahme für jede weitere Anforderung aus, sobald die Bereitstellung abgeschlossen ist:
Nicht behandelter Ausnahmeverarbeitungs-POST für Ссылка : System.IO.FileLoadException Datei oder Assembly konnte nicht geladen werden. FSharp.Core, Version = 4.3.1.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a 'oder eines seiner Abhängigkeiten. Die Manifestdefinition der lokalisierten Assembly stimmt nicht mit der Assemblyreferenz überein. (Ausnahme von HRESULT: 0x80131040) - bei WebAppFunction.Execute ... .. (etc)
Nachdem wir diese Ausnahme gesehen hatten, überprüften wir die Anwendungsbinärdateien und sahen, dass FSharp.Core.dll version 4.3.1.0 war (d. h. die aktualisierte Version war korrekt implementiert). Es scheint, dass die neu bereitgestellte Anwendung die richtige FSharp.Core.dll -Version nicht finden kann, obwohl sie im Ordner "application bin" vorhanden ist. Es scheint, dass die Anwendung möglicherweise noch ein Handle auf der alten FSharp.Core.dll Version hat.
Dieses Problem tritt nach dem Serverneustart, IISReset oder dem Wiederverwerten des IIS-Apppools auf. Unsere Lösung bestand darin, die Bereitstellung auf den vorherigen Build zurückzusetzen (mit FSharp.Core.dll v4.3.0.0 ), nach der die Anwendung wiederhergestellt wurde. Anschließend haben wir den neuen Build (mit FSharp.Core.dll v4.3.1.0 ) für jeden Server einzeln bereitgestellt, während er bei gestopptem apppool aus dem Load Balancer herausgenommen wurde, sodass während der Bereitstellung keine Last und das neue Build erfolgreich bereitgestellt wurde.
Wir haben dieses Verhalten während der Bereitstellung von Webanwendungen noch nie beobachtet, unabhängig davon, ob die Versionen der Versionen aktualisiert werden oder nicht. Ist jemand anderes jemals mit FSharp.Core.dll auf dieses Problem gestoßen, und wenn ja, kann das Verhalten erklärt werden?
Sie müssen möglicherweise die Assembly-Umleitung in Ihrer Datei web.config hinzufügen:
%Vor%Dieser Fehler, den Sie beschrieben haben, ist uns schon einmal aufgefallen (wenn auch nicht während der genauen Zeit der Bereitstellung) und das obige ist es, was es immer löst.
Tags und Links f# iis-8 asp.net-web-api2