La fonctionnalité Modifier et continuer a cessé de fonctionner dans Visual Studio 2010
La fonctionnalité Modifier et continuer de Visual Studio s'est arrêtée sur Visual Studio 2010 et je ne sais pas ce qui a causé le problème.
Je travaille sur un programme d'application Windows utilisant C #. Cette application a été initialement développée dans Visual Studio 2008, puis mise à niveau vers Visual Studio 2010.
Tout fonctionnait bien, y compris Modifier et Continuer, jusqu'à la mise à niveau de .NET Framework de 3.5 à 4.0.
Maintenant, lorsque j'utilise le mode débogage, le changement d'une ligne du code dans le IDE entraîne le message suivant:
Des modifications ont été apportées qui ne peuvent pas être compilées. L'exécution ne peut pas continuer avant le les erreurs de compilation sont corrigées.
En fait, il n'y a pas d'erreur de compilation et je dois redémarrer Visual Studio pour que les mises à jour s'exécutent.
Comment puis-je obtenir Edit et continuer à travailler à nouveau?
La fonctionnalité Modifier et continuer ne fonctionne pas avec le mot clé dynamic.
J'ai essayé de supprimer la méthode qui utilise un paramètre dynamic et le projet converti fonctionne désormais sous Visual Studio 2010.
La recherche sur Internet révèle qu’il s’agit d’un bogue signalé à Microsoft. Le lien ci-dessous a plus de détails:
Dans la vue Explorateur de solutions, cliquez avec le bouton droit de la souris sur chaque référence de références, choisissez Propriétés. Dans la vue Propriétés, signez False dans le champ des types d'interopérabilité incorporés. Cela fonctionne pour moi.
J'avais utilisé le profileur de Microsoft hier et ensuite ma fonctionnalité "Modifier et continuer" s'est échappée. Après des heures de frustration, je me suis finalement rendu compte que je devais exécuter la commande VsPerfCLREnv / globaloff de la commande Invite et redémarrer mon ordinateur. Maintenant, j'ai mon Edit et continuer à l'avenir. En passant, cela n'a rien à voir avec la plate-forme cible. Cela fonctionne avec la plate-forme cible définie sur N'importe quel processeur sans aucun problème.
J'ai eu un fichier Excel "embed interop types" == true. Quand je l'ai changé en faux, éditez et continuez à travailler.
J'ai eu ce problème dans Visual Studio 2013 et: -
- Parfois, fermer et rouvrir la solution fonctionne, mais quand cela ne fonctionne pas
- le redémarrage de Visual Studio (fermer la solution, quitter Visual Studio, rouvrir Visual Studio, rouvrir la solution, réessayer le débogage avec Edit & Continue) le résout.
Dans mon cas, aucun type Interop n'était incorporé, aucun de mes codes ne contenait le mot clé dynamic et j'avais effectué une solution complète en mode minimal sans succès. Cependant, j’avais exécuté, débogué et redémarré plusieurs fois. C’était donc peut-être dû à la mémoire - il a fallu plus d’une minute à Visual Studio pour se fermer, période au cours de laquelle le disque se débattait jouer).
J'essayerais de nettoyer tous les fichiers générés par VS. Donc, je supprimerais les répertoires bin et obj et je supprimerais également les fichiers *.suo et *.user. Étant donné que ces fichiers sont générés automatiquement, cela ne devrait affecter en rien (bien que je ferais évidemment une sauvegarde de tous les fichiers au cas où d'autres fichiers auraient été insérés par erreur).
Parfois, ces fichiers peuvent être corrompus (cela se produisait souvent dans l'ancien VC++, etc.), puis VS peut commencer à agir de manière très amusante.
J'ai essayé toutes les solutions ci-dessus, aucune d'entre elles n'a fonctionné pour moi. Cependant, lorsque je ai supprimé les dossiers bin et object dans visual studio et que je les ai exécutés à nouveau, cela a commencé à fonctionner.
Dans ma situation, quelqu'un a ajouté une référence à la sortie du projet dans la liste des références: dans l'Explorateur de solutions, recherchez-le sous [NomProjet]\Références pour [NomProjet *] et supprimez-le.
Si le projet repose sur du code provenant d'une copie de lui-même, vous ne pouvez pas "Éditer et continuer". Dans la liste d'avertissement, vous pouvez ou non (plutôt dans un projet plus important) avoir des messages "en conflit avec le type importé" si cela est la cause du problème.
Dans Visual Studio 2015, j'ai supprimé le dossier .vs (où se trouve le nouveau fichier .suo de style), supprimé tous les objets bin et obj, ainsi que désinstallé Resharper 2015 . Éditer et continuer est de retour.
(note latérale: intellisense montre maintenant l'auto-complétion presque instantanément, alors que cela prenait 2 à 5 secondes avant, peut-être de la faute de resharper, et peut-être même aucun lien entre elles ...)
en travaillant avec la communauté VS2017, j'ai eu ce problème aggravant: si vous portez un projet existant avec la balise EmbedInteropTypes peut ne pas être dans le fichier .csproj, une recherche est vaine. Si c'est le cas, ajoutez la balise à la fin du groupe de propriétés Debug | x86 (ou celui que vous utilisez) au .csproj avec un éditeur de texte:
avant:
<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>
après:
<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>
Cela doit être fait avec tous projets qui appartiennent à la solution!
Dans VS2013, je devais activer "Utiliser le mode de compatibilité gérée" dans les options de débogage. Je pense que c’est parce que j’ai un projet .Net 4 référençant un assemblage .Net 2.
Pour un autre projet dans la même solution, je devais décocher "Définir constante TRACE" dans les propriétés du projet.
Je comprends que ce message est ancien, mais j’ai eu ce problème récemment, et ce article de blog me montre comment résoudre ce problème.
- Supprimer le dossier obj
- Supprimez le dossier bin. Vous pouvez copier et coller des bibliothèques, des fichiers de données, etc. dans le dossier après leur suppression.
- Dans VS, menu Solutions -> Solution propre.
Cela fonctionne pour moi plusieurs fois.
Dans mon cas, ce qui a fonctionné, c’est décocher la case "Exiger que les fichiers source correspondent exactement à la version originale" dans les options de débogage. VS Community 2017 ici.
Pour moi, ceci est dû au fait que Nuget n'a pas réussi à télécharger un package (conçu pour Net Framework) dans un projet Net Standard référencé . Nuget est entré dans une boucle infinie (regardez dans la fenêtre de sortie).
La solution devait désactiver le paramètre 'restauration automatique du paquet', voir: https://developercommunity.visualstudio.com/content/problem/26638/nuget-infinite-loop.html
pour accéder à ce paramètre Outils> Options> Gestionnaire de paquets NuGet> Général
En lisant ce qui précède, mon projet d’interface utilisateur a Shell32 avec "Types d'interopérabilité intégrés" == true. Je l'ai changé en faux, et "éditer et continuer" a commencé à fonctionner.
Dans la vue Explorateur de solutions, cliquez avec le bouton droit de la souris sur chaque référence de références, choisissez Propriétés. Dans la vue Propriétés, signez False dans le champ des types d'interopérabilité incorporés. Cela a fonctionné pour moi.