Das Projekt enthält zurzeit Verweise auf mehrere Versionen
Wir vor kurzem ein Upgrade auf VS2012 und .NET 4.5. Seit der Umstellung auf 2012, ich erhalte immer diese Fehler beim Debuggen:
Compiler-Fehlermeldung: BC32206: Das Projekt enthält zurzeit
Bezüge zu mehr als einer version von NPGUtilities, eine direkte
Verweis auf version 2012.4.4751.24389 und eine indirekte Referenz
(durch 'AdminWeb.targetweights.sgModels') version
2012.4.4751.24391. Ändern Sie den direkten Verweis auf version 2012.4.4751.24391 (oder höher) von NPGUtilities.BC32206: Das Projekt enthält zurzeit Verweise auf mehr als einen
version EnterpriseData, einen direkten Verweis auf version
2012.4.4751.25227 und einen indirekten Verweis (über " SponsorWeb.selectplan.AdministratorXDataset1') version
2012.4.4751.25243. Ändern Sie den direkten Verweis auf version 2012.4.4751.25243 (oder höher) von EnterpriseData.
Diese beiden sind Projekt-Referenzen. Ich habe versucht, das entfernen und readding Sie aber immer noch kein Glück. Kann mir jemand einen Rat, wie dieses Problem zu beheben?
Haben Sie versucht, auf der Suche nach der Zeichenfolge "2012.4.4751.24389" in der gesamten Lösung und ersetzen Sie es mit "2012.4.4751.24391" und tun das gleiche mit der anderen Baugruppe?
InformationsquelleAutor user1955468 | 2013-01-07
Du musst angemeldet sein, um einen Kommentar abzugeben.
Konnte ich beheben dieses Problem, indem Sie alle Dateien in meinem
bin
Ordner und dann den Wiederaufbau das Projekt. Für mich das Problem war, dass die Reinigung wurde das Projekt nur löschen DLLs in diebin\Debug
Ordner, während die alten DLLs wurden noch in derbin\Release
Ordner.Sie würden denken, aber für mich ist es das nicht.
Sauber ist das größte Mysterium, da wir Feuer.
Sauber reinigt nur die aktuell ausgewählten build-Konfiguration.
InformationsquelleAutor bbodenmiller
Zunächst der workaround: ich deaktiviert, die version der Assembly Autoincrement!
Stellt fest, dass dieses problem trat nur in Vs2013 mit einer Kopie der Lösung läuft perfekt vs2010.
Vs2013 Bauen, umbauen, saubere Lösung, die manuelle Löschung ./bin oder ./obj oder %TEMP% können das problem nicht lösen. Ich komponierte auch eine neue Lösung von Grund auf in Vs2013 zu vermeiden, die Leichen von vs2010: diese neue Lösung kompiliert nur zweimal: das Dritte mal der Fehler erschien wieder, ohne dass... etwas in der Maschine blieb schmutzig.
Nun die Explikation...
Ich hatte dasselbe problem auf eine Lösung mit 86 Projekt mit der folgenden Gliederung: die '60.dll" ist die falsche dll:
Also die BC32206 Fehler mit der Grund.
Beachten Sie, dass die version unterscheiden sich nur in der revision von 23545 zu 23549 (also nur '4' - Einheit): in einigen Neuaufbau war dieser Unterschied '1' Einheit; remebering, dass diese Zahl (Sekunden seit Mitternacht/2), merkte ich, dass aus irgendeinem Grund, die '60.dll' kompiliert wurde zweimal ... Nichts zu tun: ich fand keine andere Kopie von '60.dll" mit dem datetime entsprechend höheren Wert ein anfordern '23549'. So ist es real, dass etwas verbuggt ist in Vs2013.
Also die Letzte chance: deaktiviert habe, Autoincrement und ich befestigte die Assembly-version X. Y. 0.0: dies ist völlig ausreichend für meine Zwecke, weil '60.dll" ist ein Teil einer umfassenden Veröffentlichung, und sollte niemals eingesetzt werden stand-alone (ich benutze immer noch die fileVersion durchsuchen die richtige Datei)
InformationsquelleAutor Federico Ballan
Als die Fehlermeldungen anzuzeigen, müssen Sie eine version in Konflikt mit Ihren Bibliotheken. Überprüfen Sie die version auf die Referenzen, um sicherzustellen, dass Sie übereinstimmen, oder noch besser, sicherzustellen, dass Sie mit dem Verweis auf die selbe Datei in Ihrem Haupt-und sub-Projekte.
Schnappen Sie sich eine Kopie von jedem widersprüchliche dll. Fügen Sie es zu dem sub-Projekt sauber und bauen das sub-Projekt, und fügen Sie die gleiche dll in das Haupt-Projekt und kompilieren Sie. Wiederholen Sie diesen Vorgang für jede dll/Teilprojekt. Wenn Sie dieselbe Datei Verweis, von den Haupt-und sub-Projekte der Versionen sollten übereinstimmen. Derzeit haben Sie eine neuere version in den cache für Sie Teilprojekte und es ist das Problem verursacht.
InformationsquelleAutor Kami
Ich hatte das gleiche 'scheinbare' Problem, das kostet mich einen ganzen Tag zu lösen versuchen. Ich hatte überprüft meine Projekt-Abhängigkeiten gründlich und alle wurden auf das gleiche version der betreffenden dll. Ich selbst schob meine lokalen Ordner und brachten alles wieder raus aus dem Subversion - immer noch das gleiche. Ich lief Process Explorer gesucht und die dll nur zu finden, die alte dll wurde verwiesen .NET Reflector. Ich benutzt hatte .NET Reflector ein paar Tage vor dem Debuggen einer älteren version in eine andere Visual Studio-Projektmappe und .NET Relector wurde, verweisen auf die ältere dll in den Ordnern. Diese retten könnte jemand einige Zeit.
InformationsquelleAutor John J Smith
Fand ich, dass das Problem war, denn ich hatte versehentlich das falsche start-up-Ordner.
Zum Beispiel hatte ich PROJECT_A mit einer Abhängigkeit PROJECT_B und PROJECT_A sollte das Projekt starten.
Allerdings konnte ich noch nicht erkennen, dass PROJECT_B wurde nun der start-up-Ordner.
PROJECT_A war das kompilieren mit einem alten Verweis auf die PROJECT_B dll und dann PROJECT_B wurde anschließend eine neue version erstellen und kopieren, die neue version in den bin-Ordner.
Korrektur der start-up-Ordner korrigiert dies für mich.
InformationsquelleAutor user3308158
Hatten wir ein ähnliches Problem, dass ein reinigen nicht beheben. Es stellte sich heraus, dass ein bin-Ordner bekam, in das Projekt aufgenommen, die durch Unfall, so wird die referenzierte dll bekam checked in version control. Zum Verhängnis wird, dass das hinzufügen und entfernen der dll aus dem repo hat den trick.
InformationsquelleAutor CharlieG
Konnte ich klar den gemeldeten Konflikt durch die änderung
[assembly: AssemblyVersion("1.0.*")] [assembly: AssemblyVersion("1.0.5814.0")] in der AssemblyInfo.cs-Datei von der "anstößige" - Projekt.
Basiert auf den folgenden Beobachtungen scheint dies ein IDE-Problem:
Offenbar, VS erkennt und 'caches' der Konflikt, wenn es gestartet wird. Reinigen oder neu erstellt werden, bieten keine Hilfe.
Auch, es scheint, als ob nur C# - Klassenbibliotheken bringen über dieses Verhalten.
InformationsquelleAutor David
Erlebte ich diese Fehlermeldung beim remote-debugging. Die version der referenzierten dll auf die Maschine, die gedebuggt wird funktionell identisch, aber mit einer anderen Versionsnummer auf die verwiesen wird zur compile-Zeit. Die Lösung Bestand darin, ersetzen Sie die version auf der Maschine, die gedebuggt wird.
InformationsquelleAutor user6788224
Ich dieses problem gelöst für alle Skript-Aufgaben in mein SSIS-Paket, indem Sie .DTSX-Datei und ersetzen alle Instanzen von "Microsoft SQL Server\100\SDK\Assemblies", die mit "Microsoft SQL Server\120\SDK\Assemblies.
Ich hab die 'ersetzen', dann erfrischt in VS 2013, und alle Fehler ging Weg.
Beachten Sie, dass die Referenzen wurden bereits unter Bezugnahme version 12, aber das "HintPath" wurde noch in Bezug auf die "\100\" - Pfad. Ich gehe davon aus das war die Quelle des Problems.
Hier ist eine XML-Codeausschnitt aus der .DTSX-Datei vor und nach:
BEVOR:
NACH:
InformationsquelleAutor DavidBCA
Ich ging einfach in die "NuGet" und deinstalliert alle Pakete, die in Bezug auf den Konflikt Bibliothek.
Dann habe ich vorsichtig wieder erneut installiert, machen Sie sicher, dass jedes Element hatte das gleiche (neueste) version-Nummer. Ich war mit "cEfSharp" - Module, aber installiert war eine Mischung aus der Version 57 und 51 versehen.
InformationsquelleAutor craisin
Hatte ich ein Projekt, mit JSON.net v10 und eine moderne version von ASP-Identität. JSON.net wurde mit einer älteren version des http.Formatierung dlls - Upgrade über Nuget auf die neueste Version gelöst für mich.
InformationsquelleAutor Liam
Wie andere schon wissen, dieser Fehler kann verursacht werden, weil der auto-Inkrement-Funktion in der AssemblyInfo.Datei des Projekts.
Wir hatten ursprünglich die AssemblyVersion wie
dass ich geändert, um
Dass war der Fehler. Ich begann mit diesem Problem. Ich dachte, ich würde nur brauchen, um die zu entfernen .* aber es funktioniert immer noch nicht, weil die Montage ohne .* hatte eine niedrigere Versionsnummer als die automatisch generierten.
Also die für das Update, hatte ich die assembly verwiesen wird, die namespaces Abschnitt meiner web.config-Datei. Ich entfernt und es lief das Projekt, haben Sie einige runtime-Fehler. Dann habe ich wieder die namespace-Element und der Fehler ging Weg.
Give it a shot, wenn Sie Ihre assembly im namespace " - Abschnitt Ihrer web/app.config.
EDIT: Einer meiner Kollegen hatte immer noch das Problem nachdem ich diesen trick. Eine bessere Lösung ist, einfach löschen der temporären ASP .NET Ordner. (C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Dateien)
InformationsquelleAutor jBelanger
Mein Problem wurde mit dem Microsoft.SqlServer.SMO Satz von dlls. Meine Auflösung ist völlig anders wieder zu jeder elses. Und der Hinweis: es wurde mit Visual Studio 2017, v15.8.6. Von dem, was ich sammeln können, es gibt mehrere Ursachen für dieses Problem und meine Lösung war nicht etwa der Reinigung oder Montage automatische Nummerierung.
In Arbeitsbereich 1 alles, was gebaut, sondern in Arbeitsbereich 2 hatte ich das oben genannte Problem durch: Microsoft.SqlServer.SMO-namespace hat etwa 10 oder so-dlls zu version. 8 des Dll-Dateien wurden korrekt gefunden, direkt verwiesen wird und für die bestimmte version. Aber 2 hatte ein Hauch Weg, aber waren nicht bestimmte version, und auch nicht gefunden auf den Hinweis Weg. So ist es vorgeschlagen, diese beiden um diejenigen, die finden Sie in den GAC, der auf einer neueren version. Sobald kopierte ich die fehlenden zwei dll ' s in das Hinweis-Pfad, und legen Sie Sie wie bestimmte version, alles funktioniert.
Und nur um sicher zu gehen, habe ich Sie manuell Bearbeiten Sie das Projekt-Datei, um jede Bezugnahme auf die ältere version benötigt, und auch die Assembly Binding Redirect in der app.config, um die ältere version für eine gute Maßnahme.
InformationsquelleAutor Deano
in meinem Fall, reinigen Sie und bauen fein gearbeitet
InformationsquelleAutor Hasham
Versuchen, löschen Sie alle bin/debug/* stopft
InformationsquelleAutor Xakiru