2016-11-13 4 views
0

Wir haben einen Dienst geschrieben, der in Azure implementiert werden soll. Diese besteht aus einer DLL mit einer "Worker Role" Klasse und einem Azure Cloud-Service-Projekt, wie unten dargestellt: enter image description hereFalsche Version von System.Runtime wird gepackt

Die Build-Schritte sind:

  1. die ccproj Bau in "Release" Konfiguration.
  2. Run NuGet "spec", dann "Pack", um eine Datei .nupkg
  3. Bereitstellen der .nupkg Datei in das Azure Cloud Service

Dies hat gearbeitet für eine Weile gut, bis wir ein Upgrade zu .NET 4.6.2 und aktualisiert mehrere andere Referenzen, einschließlich System.Runtime (jetzt v4.3.1). Nun, obwohl wir (unnötigerweise) einen NuGet-Verweis auf jedes einzelne-Projekt in der Lösung hinzugefügt haben und auf System.Runtime 4.3.1 verweisen, ist die Version von System.Runtime.dll, die bereitgestellt wird, eine ältere Version , was zu DLL-Fehlern auf dem Dienst führt, die dann nicht ausgeführt werden können. Wenn wir manuell die richtige Version von System.Runtime.dll kopieren, funktioniert alles wieder.

Woher kommt diese falsche Version von System.Runtime? Und wie überzeugen wir die anstößige Software/Hardware, um die richtige Version zu verwenden?

UPDATE: Trail wird wärmer. Auf meinem Entwicklungscomputer enthält der Ordner bin des EventWorker-Projekts die richtige Version von System.Runtime.dll. Aber ... der Ordner EventProcessor\obj\debug\EventWorker enthält die alte Version! Ich löschte den obj Ordner und kompilierte das Projekt neu - und die alte Version der DLL wird erneut angezeigt.

Woher kommt es und wie wird es repariert?

Antwort

0

Nun, ich habe es behoben, aber ich bin mir nicht sicher, warum das funktioniert hat. I entfernt der NuGet Verweis auf System.Runtime aus dem EventWorker Projekt. Und jetzt verwendet die EventProcessorRole die richtige Version der DLL. nur

Ich werde dies als Antwort in der Zwischenzeit markieren, aber wenn jemand eine Erklärung für dieses Verhalten zur Verfügung stellen kann, gebe ich Ihnen Kredit beantworten ...

0

Sie haben die richtige Idee in Bezug auf die Suche nach der beanstandeten DLL. Haben Sie irgendwelche abhängigen DLLs, die die falsche Version verwenden könnten? Wenn es lokal ausgeführt wird, zeigt es Ihnen außerdem die DLL-Konfliktwarnung im Fehlerfenster an, so dass Sie erkennen können, wo? Werfen Sie einen Blick auf Ihre Konfigurationsdatei und sehen Sie, ob Sie einen Verweis auf die DLL-Version im Redirects-Bereich haben, aktualisieren Sie sie oder erstellen Sie einen neuen, um auf die neueste Version zu verweisen.

+0

Es gibt keine Konfliktmeldungen bei der Kompilierung, zur Laufzeit bei der Bereitstellung in Azure. Aber jetzt habe ich einige neue Informationen gefunden - siehe Update zu meiner Frage. –

+0

Zu meinem letzten Punkt, gibt es einen Verweis darauf im Abschnitt Weiterleitungen Ihrer app.config im Worker? Wenn dies eine Version angibt, ist es egal, was Sie hinzufügen, und es funktioniert, da Sie die alte Version lokal haben. Deshalb funktioniert es nicht in der Cloud. –

+0

'app.config' hat:' ' –

Verwandte Themen