Fehler CS1705: "die eine höhere Version als die referenzierte Assembly hat"

Ich habe mich jetzt ein bisschen damit befasst und es nicht gelöst. Ich erhalte die folgende Fehlermeldung:

Compiler Error Message: CS1705: Assembly 'My.Model, Version=1.1.4422.23773, Culture=neutral, 
PublicKeyToken=bfde95ba233094b2' uses 
'Common, Version=3.3.4273.24368, Culture=neutral, PublicKeyToken=bfde95ba233094b2' 
which has a higher version than referenced assembly
'Common, Version=3.3.4269.17112, Culture=neutral, PublicKeyToken=bfde95ba233094b2'

c:\WINDOWS\assembly\GAC_MSIL\Common\3.3.4269.17112__bfde95ba233094b2\Common.dll: 
(Location of symbol related to previous error)

Auf dem Webserver wird Server 2003 ausgeführt. Ich ging zu c: \ windows \ Assembly und stellte fest, dass drei Versionen von Common.dll aufgelistet waren. Die höchste aufgeführte Version war 3.3.4269.17112

Ich habe die DLL mit der Version 3.3.4273.24368 in das Assembly-Verzeichnis kopiert. Ich habe dann meinen Code neu kompiliert und erneut bereitgestellt (wahrscheinlich übertrieben, aber na ja). Als ich meinen Browser in einer neuen Sitzung öffnete und erneut zur Site-URL ging, wurde immer noch dieselbe Nachricht angezeigt.

Ich kann den Windows Explorer verwenden und überprüfen, ob die Common.dll mit höherer Version jetzt ebenfalls aufgeführt ist.

Was kann ich noch prüfen, um dieses Problem zu beheben? Ich möchte die Referenz in meiner Assembly nicht so ändern, dass sie auf die ältere Version verweist.

3 Ideen, die Sie ausprobieren sollten:

1. Stellen Sie sicher, dass alle Ihre DLLs mit derselben Version von Common kompiliert wurden.
2. Überprüfen Sie, ob Ihre Lösung Projektreferenzen anstelle von Dateireferenzen enthält.
3. Verwenden Sie Bindungsumleitungen in Ihrer web.config. ( Ursprünglich verknüpfte Version auf der Wayback-Maschine )

Ich hatte diesen Fehler, weil "Rebuild" nicht wirklich neu aufgebaut wurde.

Lösung: Schließen Sie Visual Studio, löschen Sie den Ordner bin und löschen Sie ihn erneut. Möglicherweise funktioniert er besser.

Manchmal lügt Visual Studio auch über Referenzen. Überprüfen Sie dies HintPathin Ihren .csprojDateien.

Wenn Sie NuGet verwenden, sollten Sie unter "Verwalten von NuGet-Paketen für Lösungen" nach dem Paket suchen, das Probleme verursacht, und auf "Aktualisieren" klicken. Es sollte dann alle Pakete auf die neueste Version bringen und das Problem beheben.

Einen Versuch wert, da es schnell und einfach geht.

Mein Problem war, dass ich 2 Projekte hatte, die auf 2 verschiedene Kopien derselben DLL mit unterschiedlichen Versionen verweisen. Ich habe es behoben, indem ich beide entfernt und sichergestellt habe, dass sie auf dieselbe DLL-Datei verweisen.

Eine mögliche Ursache ist, dass die zweite Baugruppe in GAC installiert ist, während die erste Baugruppe mit einer höheren Versionsnummer zu den Referenzen des Projekts hinzugefügt wird. Um dies zu überprüfen, doppelklicken Sie in den Projektreferenzen auf die Assembly und prüfen Sie, ob im Objektbrowser eine andere Assembly mit demselben Namen vorhanden ist.

Verwenden Sie in diesem Fall das Dienstprogramm gacutil.exe, um die zweite Assembly vom GAC zu deinstallieren. Wenn es sich beispielsweise um 64-Bit-Assemblys handelt:

C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\x64\gacutil.exe -u <assembly_name>

Gehen Sie zu Referenz und fügen Sie eine neue Referenz Ihrer DLL-Datei hinzu, die das Problem verursacht, und stellen Sie sicher, dass alle Ihre DLLs mit derselben Version kompiliert wurden. Es funktioniert bei mir Ich hoffe es funktioniert auch bei Ihnen.

Mein Team ist gerade in unserer Build-Umgebung auf dieses Problem gestoßen. Das Problem war auf einen Unterschied im <HintPath> -Element der .csproj-Datei zurückzuführen.

Unsere gemeinsame Assembly hatte einen korrekten relativen Pfad zu dem Verzeichnis, das unsere Referenzassemblys enthält. Die abhängige Assembly hatte einen Pfad von einer früheren Verzeichnisstruktur. Die Lösung wurde erfolgreich auf Entwicklungscomputern kompiliert, da der GAC den Verweis des Abhängigen auf die richtige Version in C: \ Programme auflöste. Die Build-Umgebung hatte eine Legacy-Installation der Assembly (obwohl sie keine hätte haben sollen), auf die sie zurückgegriffen hat, und damit den Fehler. Das Aktualisieren des <HintPath> in einem Texteditor hat das Problem behoben.

Das Problem tritt auf, wenn die Nuget-Pakete in mehreren Projekten innerhalb der Lösung variieren.

Sie können dies beheben, indem Sie Nuget-Pakete mit allen PROJEKTEN in der LÖSUNG auf eine gemeinsame Version aktualisieren

Hatte ein ähnliches Problem. Mein Problem war, dass ich mehrere Projekte innerhalb derselben Lösung hatte, die jeweils auf eine bestimmte Version einer DLL verweisen, jedoch auf unterschiedliche Versionen. Die Lösung bestand darin, 'Spezifische Version' in allen Eigenschaften aller Referenzen auf false zu setzen.

Ich weiß, dass dies vor einiger Zeit gefragt wurde, nachdem ich einige der oben genannten Schritte ausprobiert hatte. Was mir geholfen hat, waren die folgenden Schritte und dieser Artikel .

Ich habe die Referenz gefunden und das PublicKeyToken von dem, auf das verwiesen wird, in das ältere geändert.

Ich hoffe das hilft auch.

Ich hatte den gleichen Fehler. Ich habe den Fehler nach der Installation Microsoft.AspNetCore.ALLin einem Testprojekt behoben .

Handgemachte DLL Sammelmappe
Wenn Sie Lösung einen Müll - Ordner für DLL-Dateien aus verschiedenen Bibliotheken
lib, source, libsetc.
Sie können diese Probleme bekommen , wenn Sie Ihre Lösung öffnen werden (für eine Tanne Zeit) in Visual Studio. Und der Sammelordner Ihrer DLL fehlt irgendwie oder eine konkrete DLL-Datei fehlt.

Visual Studio wird stillschweigend versuchen, die Referenz der DLL durch etwas Eigenes zu ersetzen. Wenn VS erfolgreich ist, bleibt eine neue Referenz für Ihre lokale Lösung bestehen. Nicht für andere Klone / Kassen.

Dh Ihr <HintPath>wird ignoriert und Ihre Projektdatei (.csproj) wird nicht geändert.
Als Beispiel für mich

<Reference Include="DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..\..\..\lib\DocumentFormat.OpenXml.dll</HintPath>
</Reference>

Auf die DocumentFormat.OpenXmlwird C:\Program Files (x86)\Open XML SDK\V2.5\libnicht aus einem solution\..\libOrdner verwiesen .

schnelle Problemumgehung

• Überprüfen Sie den Sammelordner Ihrer DLL und stellen Sie ihn wieder her
• Entladen Sie im Projektmappen- Explorer das Projekt und laden Sie das Projekt neu .

Die richtige Problemumgehung besteht darin, auf den NuGet-Paketmanager zu migrieren.

Stellen Sie für SharePoint sicher, dass Sie unter Ihrem Stammordner keinen "bin" -Ordner mit Ihren DLLs haben. Wenn ja, löschen Sie ihn einfach. (und ändern Sie "Copy Local" in VS in false).

Die Referenzen in einem Website-Projekt werden in der Datei web.config gespeichert. Aktualisieren Sie dort die Referenz, um den Fehler zu beheben.

Ich habe einige Zeit damit verbracht, alle Referenzen in meiner Lösung zu untersuchen, bevor mir klar wurde, dass ich die Referenzen in der Datei web.config vergessen hatte.

Ich hatte das gleiche Problem mit UnitTestingProject, bei dem ich im MainProject "System.Web.Mvc, Version = 3.0.0.0" und in UnitTestingProject "System.Web.Mvc, Version = 3.0.0.1" verwendete.

Ändern Sie Folgendes in der <Reference Include="System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"> <HintPath>..\packages\Microsoft.AspNet.Mvc.3.0.50813.1\lib\net40\System.Web.Mvc.dll</HintPath> </Reference>

Ich habe dies erhalten, nachdem ich Episerver Find zu unserer Site hinzugefügt und das entsprechende NuGet-Paket für Episerver Find installiert habe.

Das Update war einfach: Aktualisieren Sie auch alle Episerver-bezogenen Add-Ons (auch wenn sie nicht miteinander zusammenhängen: CMS, CMS.TinyMCE, CMS.UI usw.)

Nach dem Aktualisieren aller möglichen Episerver-Add-Ons und dem erneuten Kompilieren ist der Fehler behoben.

In meinem Szenario habe ich die .csproj-Datei für meine dotnetCore-App bearbeitet. Ich habe festgestellt, dass das TargetFramework- Tag den Wert netcoreapp2.1 und das RuntimeFrameworkVersion- Tag den Wert 2.0.0 hat . Also habe ich das geändert RuntimeFrameworkVersion bis 2.1.0 , gespeichert, neu gestartet VS und neu aufgebaut und dann die Fehler es gelöst.

Hoffe das wird dir helfen ...

Viel Glück,

Sugeshan

Suchen Sie in Ihrem Projekt nach Referenzen. System.Web.Mvc Überprüfen Sie die Version.

Nach , dass Rechtsklick Referenzen -> Baugruppen und suchen System.Web.Mvc und Setup es.

Das Problem verursacht die verschiedenen Versionen dieser Assemblys .

Bearbeiten: Wählen Sie dann NuGet-Pakete verwalten und installieren Sie die Updates (wenn Sie mehrere Projekte haben, installieren Sie auch Updates für diese.)

Wichtiges Update ist Microsoft.AspNet.Mvc und Microsoft.Net.Compiler vergessen es nicht!

In unserem Team haben wir mit git an verschiedenen Computern gearbeitet. Jemand hat a aktualisiert dllund ich hatte es nicht. Ich habe gerade meine Abhängigkeitsreferenzen aktualisiert und das Problem gelöst.

Ich hatte ein ähnliches Problem, ich hatte eine DLL erstellt, dh A.dll, die auf andere DLLs verwies, dh B.dll.

Ich habe eine Anwendung C.exe erstellt und auf die DLLs A.dll und B.dll verwiesen.

Lösung - Beim Entfernen der Referenz von B.dll aus c.exe konnte ich das Problem beheben.

Hoffe das hilft.