Bearbeiten und Fortsetzung Die Funktion wurde nicht mehr in Visual Studio 2010 arbeiten

https://stackoverflow.com/questions/4782057

23-10-2019
|

Frage

Die Funktion Visual Studio bearbeiten und kontinuierlich hat bei Visual Studio 2010 gestoppt, und ich weiß nicht, was das Problem verursacht hat.

Ich arbeite an einem Windows -Anwendungsprogramm mit C#. Diese Anwendung wurde ursprünglich in Visual Studio 2008 entwickelt und später auf Visual Studio 2010 aktualisiert.

Alles funktionierte gut, einschließlich Bearbeiten und Weiter, bis ich das .NET -Framework von 3,5 auf 4,0 aktualisierte.

Wenn ich nun den Debug -Modus verwende, führt die Änderung einer Zeile des Codes in der IDE in der folgenden Nachricht:

Es wurden Änderungen vorgenommen, die nicht zusammengestellt werden können. Die Ausführung kann nicht fortgesetzt werden, wenn die Kompilierfehler behoben sind.

Tatsächlich gibt es keine Kompilierungsfehler, und ich muss das Visual Studio neu starten, damit die Updates ausgeführt werden können.

Wie kann ich bearbeiten und weiter arbeiten?

Lösung 2

Die Funktion für Bearbeiten und Fortsetzung funktioniert nicht mit der dynamic Stichwort.

Ich habe versucht, die Methode zu entfernen, die a verwendet dynamic Parameter und das konvertierte Projekt funktioniert jetzt auf Visual Studio 2010.

Internetforschung zeigt, dass dies ein Fehler ist, der Microsoft gemeldet wurde. Der folgende Link enthält weitere Details:

Dynamisches Objekt als Methodenparameter bricht das Bearbeiten und fordern Sie für die Klasse und das Projekt fort

Andere Tipps

Klicken Sie in der Lösungs-Explorer-Ansicht mit der rechten Maustaste auf jede Referenzreferenz und wählen Sie Eigenschaften. In der Eigenschaftenansicht unterzeichnen Sie das Feld der Einbetten -Interop -Typen falsch. Das funktioniert für mich.

Ich hatte eine Excel -Datei "embed interop types" == true. Als ich es in Falsch geändert habe, bearbeiten und fingen Sie weiter zu arbeiten.

Ich hatte gestern Microsofts Profiler verwendet und danach ist meine Funktion "Bearbeiten und Fortsetzung" entkommen. Nach stunden Stunden der Frustration merkte ich schließlich, dass ich ausführen musste Vsperfclrenv /GlobalOff -Befehl von der Eingabeaufforderung und starten Sie meinen Computer neu. Jetzt habe ich meine Bearbeitung und fähre die Zukunft fort. Es hat übrigens nichts mit der Zielplattform zu tun. Es funktioniert mit der Zielplattform, die ohne Probleme auf eine beliebige CPU eingestellt ist.

Ich hatte dieses Problem in Visual Studio 2013 und:-

Manchmal funktioniert das Schließen und Wiedereröffnung der Lösung, aber wenn das nicht
Neustart Visual Studio (Close Solution, Exit Visual Studio, Wiedereröffnung von Visual Studio, Wiedereröffnung von Lösung, Wiederläufung von Debugging mit Bearbeiten und Fortsetzung) behebt es.

In meinem Fall hatte ich keine eingebetteten Interop -Typen, noch hatte keiner meiner Code das dynamic Schlüsselwort, und ich hatte eine vollständige Lösung ohne Erfolg durchgeführt. Ich hatte jedoch viele Male gelaufen, debuggen und neu gestartet abspielen).

Ich würde versuchen, alle Dateien zu reinigen, die von Vs. Also würde ich das löschen bin und obj Verzeichnisse und ich würde auch löschen *.suo und *.user Dateien. Da diese Dateien automatisch generiert werden, sollte dies nichts beeinflussen (obwohl ich natürlich eine Sicherung aller Dateien machen würde, falls es einige andere Dateien gibt, die dort versehentlich eingegeben wurden).

Manchmal können diese Dateien beschädigt werden (es passierte früher ziemlich viel im alten VC ++ usw.) und dann können VS anfangen, sich sehr lustig zu verhalten.

Ich habe alle oben genannten Lösungen ausprobiert, die keiner von ihnen für mich gearbeitet hat. Aber wenn ich löschte die Ordner "Behälter und Objekte" In Visual Studio und wieder rennen es zu funktionieren.

Arbeiten mit VS2017 Community Ich hatte dieses erschwerende Problem: Wenn Sie ein vorhandenes Projekt portieren, das Tag Einbettinteroptypen Möglicherweise befindet sich noch nicht in der .csproj -Datei, eine Suche ist zwecklos. Wenn dies der Fall ist, fügen Sie das Tag am Ende dem Eigenschaftsgruppen -Debug | x86 (oder dem, was Sie verwenden) mit einem Texteditor zum .csproj hinzu:

Vor:

  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
    <DebugSymbols>true</DebugSymbols>
    <OutputPath>bin\x86\Debug\</OutputPath>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <DocumentationFile>bin\Debug\MyProject.XML</DocumentationFile>
    <DebugType>full</DebugType>
    <PlatformTarget>x86</PlatformTarget>
    <ErrorReport>prompt</ErrorReport>
    <Prefer32Bit>false</Prefer32Bit>
  </PropertyGroup>

nach:

  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
    <DebugSymbols>true</DebugSymbols>
    <OutputPath>bin\x86\Debug\</OutputPath>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <DocumentationFile>bin\Debug\MyProject.XML</DocumentationFile>
    <DebugType>full</DebugType>
    <PlatformTarget>x86</PlatformTarget>
    <ErrorReport>prompt</ErrorReport>
    <Prefer32Bit>false</Prefer32Bit>
    <EmbedInteropTypes>false</EmbedInteropTypes>
  </PropertyGroup>

Dies muss mit geschehen alle Projekte, die zur Lösung gehören!

In VS2013 musste ich in den Debugging -Optionen "Verwaltungskompatibilitätsmodus verwenden" aktivieren. Ich denke, es liegt daran, dass ich ein .NET 4 -Projekt habe, das auf eine .NET 2 -Assembly verweist.

Für ein anderes Projekt in derselben Lösung musste ich in den Projekteigenschaften "Spurenkonstante definieren" deaktivieren.

In meiner Situation fügte jemand einen Verweis auf die Ausgabe des Projekts in die Referenzliste hinzu: In Lösungsexplorer schauen Sie unter [ProjectName] Referenzen für [ProjectName*] und entfernen Sie es.

Wenn sich das Projekt auf Code aus einer Kopie von sich selbst stützt, können Sie nicht "bearbeiten und fortfahren". In der Warnliste können Sie (wahrscheinlicher in einem größeren Projekt) "Konflikte mit importierten Typen" -Nachrichten haben oder nicht, wenn dies die Ursache des Problems ist.

In Visual Studio 2015 habe ich den Ordner .vs (in dem die neue Style .Suo -Datei) gelöscht, alle Bin und OBJ gelöscht und auch Deinstallierte Resharper 2015. Bearbeiten und Weiter ist zurück.

(Randnotiz: IntelliSense zeigt jetzt fast sofort Autokompetenz, während es 2 bis 5 Sekunden zuvor dauerte, vielleicht um Resharpers Schuld und vielleicht nicht verwandt ...)

Ich verstehe, dieser Beitrag ist alt, aber ich hatte dieses Problem in letzter Zeit und das Blogeintrag Zeigt mir, wie man es repariert.

Löschen die obj Mappe
Löschen die Behälter Mappe. Sie können Bibliotheken, Datendateien usw. kopieren und einfügen und nach dem Entfernen zurück zum Ordner zurückkehren.
Von vs, Menülösungen -> Saubere Lösung.

Das funktioniert mehrmals für mich.

Für mich wurde dies durch verursacht von Nuget Das Herunterladen eines Pakets (erstellt für Net Framework) in ein NET -Standardprojekt, auf das verwiesen wurde. Nuget trat in eine unendliche Schleife ein (schauen Sie im Ausgangsfenster).

Das Lösung sollte die Einstellung "Automatic Paket Restore" ausschalten, siehe: https://developerity.visualstudio.com/content/problem/26638/nuget-infinite-loop.html

So greifen Sie auf diese Einstellung zuTools> Optionen> Nuget -Paket -Manager> Allgemeines

Wenn ich das oben genannte liest, hat mein UI -Projekt Shell32 mit "Einbettinterop -Typen" == True. Ich habe es in False geändert und "Bearbeiten und Weiter" begann zu arbeiten.

Denn wer bekommt diesen Fehler noch mit Visual Studio 2017

Keine dynamischen/tragbaren Klassenbibliotheken/Nuget -Pakete oder Abhängigkeitsprobleme. Visual Studio wurden keine Fehler oder Warnung hervorgehoben.

Nach Stunden damit verbracht, alle darin veröffentlichten Lösungen zu probieren und andere Themen und Webseiten, die einzige Lösung, die für mich funktioniert hat Check-in, den Arbeitsbereich entfernen und Map&Get wieder.

Um den Arbeitsbereich zu entfernen, Source control → Advanced → Workspace → Remove.

Ich verwende Visual Studio 2017 Community auf dem neuesten Stand und nach einer relativ frischen Installation auf einer neuen Maschine (eine Woche und wenige Arbeitszeiten).

Methoden, die ich vor der obigen Lösung ohne Erfolg getestet habe

Ich sorgte dafür, dass Edit & Continu in Visual Studio -Optionen aktiviert war. Unkontrolliert und ticke es wieder zurück
Löschen von Bin und OBJ für alle Projekte in Lösung
Reinigen und wieder aufbauen, starten Sie VS / Neustart in Kombination zum oben genannten
Überprüfen Sie Kompilierungsoptionen, Nuget -Pakete und DLL -Kompatibilität für die Projekte, inspiriert von von Dies
Entladen der Projekte in verschiedenen Kombinationen, um Abhängigkeitsprobleme oder andere Probleme zu testen (inspiriert von Dies)
Löschen von Lösung und neu herunterladen (ohne den Arbeitsbereich zu entfernen)
Sign FALSE, um Interop -Typen einzubetten
Satz <_ResolveReferenceDependencies> zu true wie erklärt hier
Kombinationen der oben genannten mit Neustart von VS und Neustarts

Danach habe ich ein Check-in erstellt und die Lösung auf einer anderen Maschine heruntergeladen, die dieselbe Version von Visual Studio (2017 Community) ausführt. Da ich dort nicht das Problem der Bearbeitung und Weitergabe bekam, habe ich mich für die Entfernung des Arbeitsbereichs entschieden.

In meinem Fall war das, was funktioniert hat Das Deaktivieren "Erfordern Sie Quelldateien, um genau mit der Originalversion übereinstimmen" in Debugging -Optionen. Vs Community 2017 hier.

Ich musste in Tools -> Optionen -> Debugging -> Allgemein: "Native bearbeiten und fortfahren" deaktivieren.

Das Entfernen der * aus den Montageversionen meiner referenzierten Projekte löste das Problem für mich.

Von Github:

"Ich habe dieses Problem bei einer Mischung aus VB- und C# -Projekten mit [Assembly: Assemblyversion (1.2.3.*")] Reproduziert. Sobald ein VB -Projekt verweist, beginnt ein C# -Projekt mit dem Zusammenbruch. Es sieht so aus, als hätte es das gleiche Problem umgekehrt. "-Rhuijben

https://github.com/dotnet/roslyn/issues/28224

(Das Risiko, dass wir markiert werden, scheinen wir seit über einem Jahrzehnt unter den Problemen mit dem Bearbeiten und Fortsetzung von Problemen zu leiden. Es ist für mich schockierend, dass das Microsoft Visual Studio -Team nicht genug gekümmert hat, um den Entwicklern zu helfen, indem sie mehr ausführlichere Informationen zur Verfügung stellen.)

Ich habe all die oben genannten versucht, keiner hat funktioniert. Es war anscheinend darauf zurückzuführen, dass einige Debugging-Optionen auf niedrigem Niveau (Register anzeigen ...) ermöglicht wurden.

Tools -> Einstellungen importieren und exportieren -> alle Einstellungen zurücksetzen

löst es auf

In VS 2015 wurde dieser Fehler durch ein Nuget -Paket verursacht, das ich kürzlich installiert hatte. Durch das Deinstallieren dieses Pakets und die Neuinstallation wurde der Fehler behoben.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow