Erreur de compilation: “Le processus ne peut pas accéder au fichier car ce fichier est utilisé par un autre processus”
J'ai un C# webforms application, que jusqu'à aujourd'hui avait été fonctionne à merveille.
Maintenant, aujourd'hui, tout d'un coup, à chaque fois que j'essaye d'exécuter l'application, j'obtiens un fichier de verrouillage d'erreur:
Impossible de copier le fichier "obj\Debug\MyProject.exe" pour "bin\Debug\MyProject.exe". Le processus ne peut pas accéder au fichier "bin\Debug\MyProject.exe" car il est utilisé par un autre processus.
Googler l'erreur de ne pas trouver quelque chose au-delà de ce qui est évident, c'est à dire VS pense que le fichier est verrouillé. Et c'est certainement Visual Studio lui-même qui verrouille le fichier, parce que quand je ferme les VS et le rouvrir, le projet s'exécute fine - pour la première fois. Quand j'essaie de le lancer une seconde fois, j'obtiens le fichier de verrouillage de l'erreur.
De clôture VS et réouverture à chaque fois que je veux lancer l'application n'est pas une solution viable! Comment puis-je savoir quel est le verrouillage du fichier, et l'empêcher de s'enfermer?
EDIT: une Autre découverte intéressante: je n'ai même pas à exécuter l'application. Juste pour le compiler entraîne une fois le fichier de verrouillage; je ne peut pas compiler deux fois de suite!
Ce problème est spécifique à un projet dans ma solution. Tous les autres projets beau travail et peut être exécuté autant de fois que je le souhaite. C'est seulement ce un projet qui devient lui-même enfermé.
- pouvez-vous essayer de tuer le vshost.exe pour voir si cela aide?
- il n'y a pas vshost.exe processus. Ont-ils renommez-le dans VS 2010?
- [nom de votre app].vshost.exe
- non, rien ne s'affiche dans les processus actuels de ce nom
- actuellement, vous avez la question et de la [app].vshost.exe n'est pas en cours d'exécution?
- correct.
- avez-vous ajouté un personnalisé usercontrol à votre formulaire? essayez de fermer le concepteur avant l'exécution: stackoverflow.com/questions/2690119/...
- Oui, j'ai personnalisé usercontrols. Non, la fermeture de la designer n'aide pas. J'ai fermé toutes les fenêtres, et toujours l'erreur vient.
- avez-vous vérifié les liens dans la réponse de Bradly? Pouvez-vous dire quelque chose de plus au sujet de ce projet spécifique? Fait-il référence des trucs? un tiers des trucs? T4 de génération de passe? personnalisés fichier de build? clickonce? Pouvez-vous compilez le *.csproj fichier à partir de la ligne de commande en deux fois?
- Essayé les liens de @Bradley, aucune aide. Le projet est un Winforms EXE, y compris plusieurs contrôles personnalisés. Jamais fait une ligne de commande de compilation avant. L'aide de microsoft sur le sujet est totalement inutile. Comment voulez-vous faire?
- Trouvé comment le faire avec MSBuild. Fonctionne très bien à partir de la ligne de commande, et il n'est pas verrouiller le fichier. Fichier verrouille uniquement lors de la compilation dans VS 2010.
- Regardez cette SORTE: stackoverflow.com/questions/2895898/...
- Pourquoi cette question est projeté? Il n'y a pas vraiment de solution acceptable au problème dans les réponses.
Vous devez vous connecter pour publier un commentaire.
J'ai trouvé une solution simple qui fonctionne pour moi. Il va comme ceci:
Lorsque le problème se produit, il suffit de changer la configuration des bâtiments du haut (si dans “Libération” à “Debug” et vice-versa), de construire et ensuite revenir à la configuration précédente et de construire à nouveau.
Je suppose que la modification de la configuration des communiqués de la vcshost et devenv.
Bien, j'ai résolu le problème moi - même si j'ai toujours aucune idée pourquoi. J'ai décidé d'isoler le problème en supprimant tous les fichiers du projet, puis de rajouter et de déterminer de cette façon, le fichier qui a été la source de mes ennuis. Alors, un par un, j'ai réintroduit des fichiers au projet, compilé & nettoyé à chaque étape du chemin... jusqu'à ce que... j'ai ajouté la dernière...
... et tout a bien fonctionné.
J'ai fait une comparaison pour le contrôle de la source de mon original .csproj; pas de réelles différences. Et même quand j'ai essayé de revenir à la version précédente de la .csproj, il travaillait encore.
La magie noire. Si cela fonctionne, parfois, il est préférable de ne pas demander pourquoi - il suffit de l'accepter et passer à la suite...
EDIT: Le problème est récurrent, et je crois que j'ai isolé lorsque j'ai le concepteur de formulaires ouvrir un abrégé/forme générique au moment de la compilation.
Leçon apprise: assurez-vous que le Concepteur de Formulaire de résumé ou de formes génériques ou des contrôles est fermé avant de compiler! Si non, vous devez fermer la VS et de la rouvrir!
Ce que nous avons découvert ici, est la suivante:
Dans la page des propriétés du projet, onglet Débogage, décochez la case "Activer le processus d'hébergement visual studio".
Je ne suis pas certain que cette propriété est pour, mais il fait le travail une fois décochée.
En fait, vous devriez vouloir "Activer le processus d'hébergement Visual Studio" est cochée. Au moins pour VS2010 de toute façon. Et j'ai aussi:
si existent "$(TargetPath).verrouillé" del "$(TargetPath).verrouillé"
si exister "$(TargetPath)" s'il n'existe pas "$(TargetPath).verrouillé" déplacer "$(TargetPath)" "$(TargetPath).verrouillé"
dans le pre-build options. Ce problème a accablé de moi pour un temps très long et il n'était pas jusqu'à ce que John W. mentionné cette case à cocher que j'ai même pris l'avis qu'il a existé et faible et voici, il était déjà décochée.
Également remarquer que l'-app-vshost.exe s'exécute en arrière-plan, même lorsqu'il n'est pas de débogage. Qui est ce qui le rend réussir à construire et exécuter à chaque fois, je suppose. Il n'était pas en cours d'exécution avant. Et j'ai aussi essayé de nettoyer le debug et release dossiers et de changer le type de cible en permanence et rien n'a fonctionné, sauf tel que décrit ci-dessus. Ma solution avant était juste attendre 5 minutes entre deux builds, qui s'est super gênant et fastidieux à faire n'importe quoi. Je n'ai pas vu de changement dans le comportement où il est important de noter que des onglets ouverts ou XNA vs windows form ou designers en cours d'ouverture. Ce problème s'est produite en 32-bit ou 64-bit construit et n'a pas d'importance si je l'ai tué d'une application avec ALT-F4 ou de le tuer avec le gestionnaire de tâches, ce qui serait, en théorie, de ne pas autoriser l'application à se fermer ou de libérer des ressources. Au début, je pensais que c'était une collecte des ordures question.
Peu tard pour la réponse, mais je résoudre ce problème en allant dans les propriétés du projet > onglet "Debug" > décocher l'option "Activer le processus d'hébergement Visual Studio".
VS2017 - Résolu par la fermeture de toutes les instances de MSBuild.exe dans le gestionnaire des tâches de windows
J'ai surmonté ce problème en renommant le fichier verrouillé (à l'aide de l'Explorateur Windows). Je n'étais pas autorisé à supprimer le fichier, mais le changement de nom du fichier verrouillé fonctionne!
J'ai résolu ce problème en supprimant le dossier bin\Debug et, éventuellement, le redémarrage de VS
Pour moi, c'est un Service Windows qui a été installé et en cours d'exécution. Une fois, j'ai arrêté de le construire a été un succès.
Exécuter cette commande à partir de la boîte de dialogue Exécuter:
et puis
a fonctionné pour moi.
vs 2003
Il suffit de vérifier les références et supprimer l'auto-référence pour le projet.
Explication: Mon problème a commencé après la création d'un contrôle personnalisé et faites-le glisser et le déposer dans la boîte à outils de la palette pour l'utiliser dans la conception de formulaires. Première apparition d'un avertissement disant qu'il y a une redondance entre le contrôle personnalisé de fichier source (.cs) et les projets de l'exécutable (.exe). Sur l'exécution/débogage est apparu le message d'erreur: impossible d'accéder à la (.exe) parce qu'il est utilisé (et c'était vrai).
J'ai littéralement enlevé le code source en entier concernant le contrôle personnalisé et le problème persiste toujours, jusqu'à ce que j'ai vérifié les références et il faisait référence à lui-même afin d'être "en mesure de" faire entrer les anciens de contrôle personnalisé. J'ai supprimé la référence et fait!!
J'ai eu le même problème sur mon Xamarin application dans visual studio et il a été résolu en débranchant mon test de l'appareil mobile. L'application a été fermée et le débogueur a été arrêté mais l'erreur a été encore qui se passe lorsque vous essayez de construire ou de reconstruire la solution. Il ne s'arrêta après j'ai débranché l'appareil, car je devais recevoir un appel.
Juste à jeter dans mes 2 cents. Mon problème a été résolu en ouvrant le Gestionnaire des Tâches et tuer l'application. Il était en cours d'exécution en arrière-plan sans aucune indication qu'il était en cours d'exécution à tous (aucun élément dans la barre de tâche, pas d'interface utilisateur, rien), mais je ne suis pas sûr de savoir pourquoi cela est arrivé. Évidemment, le débogueur n'était pas en cours d'exécution et je n'ai eu qu'une seule instance de VS ouvert à l'époque. Cela m'étonne que c'est toujours le cas dans ce VS 2017.
Peut-être que je peux ajouter une étape de génération qui ressemble pour l'application de l'exécution de l'arrière-plan et le tue avant de commencer la nouvelle.
Comment est votre application web configuré? Il tourne sous Cassini (le plateau de serveur web) ou IIS?
Cela ne devrait pas arriver normalement. Je pense que ProcessExplorer peut vous dire quels sont les fichiers d'un processus est verrouillé. Si pas de processus d'explorer l'un des autres outils sysinternals.
Une chose à essayer avant même de télécharger l'un de l'ES outils est d'arrêter le serveur web Cassini, et voir si ça libère le fichier.
Ce qui a fonctionné pour moi a été de redémarrer IIS
j'ai eu ce même problème. changer le debug/release config n'a pas fait l'affaire. du moins pas sans le bâtiment entre les.
dans ma solution (winform), il a été résolu par l'ouverture de la mainform de la winform dans le concepteur. commutation de code (F7). Puis de fermeture le code, la fermeture de la designer de la winform et la reconstruction de tous les (ctrl-maj-B). Cela a fonctionné pour moi.
semble comme une sorte de poignée de l'intérieur de l'application winform (qui s'exécute en un backgroundworker) avait encore un descripteur de fichier sur certains des autres bibliothèques utilisées.
Récemment rencontré ce problème lors de la tentative de construire une solution, je suis en train de travailler sur (et pas seulement un winforms proj).
En plus de
buildéchec, j'ai remarqué que des projets de nettoyage discrètement échec (vérification du dossier bin a montré que les fichiers n'ont pas réellement été effacés) et de fermeture de Visual Studio n'a pas la fin de ladevenvprocessus plutôt, il a provoqué le blocage. Windows processus de récupération serait alors redémarrer Visual Studio.Après quelques essais et erreurs, j'ai trouvé que les problèmes qui m'est arrivé lorsque j'ai ouvert la solution de la "Récente" menu de démarrage VS.
L'ouverture de la solution de
File >> Open >> Project/Solutiontrouvé de travail, comme par habitude.Actuellement aucune idée de pourquoi - allons continuer à chercher cela, mais pour l'instant, au moins je peux travailler!
J'ai eu deux instances de Visual Studio ouvert la même solution.
Dans mon cas, il y avait quelques vstest processus en cours d'exécution (avec des noms différents, mais tous contenant la chaîne de caractères vstest). J'ai dû y mettre fin dans taskmgr.
Même erreur, résolu par la mise à jour de Google support packages Nuget
Quand j'ai terminé le processus
.Net Core Host, tout construit amende. Je n'ai pas besoin de fermer Visual Studio ou de faire changer quoi que ce soit d'autre.Pour ceux qui sont en développement en VS avec Docker, redémarrez le menu fixe pour le service windows et le problème sera résolu immédiatement.
Avant de redémarrer le panneau, j'ai essayé tous les réponses, n'est-ce pas trouver un msbuild.exe processus en cours d'exécution, a également essayé de redémarrer VS, sans succès, seul le redémarrage de docker travaillé.
Eu le même problème, donc ouvert le gestionnaire des tâches(comme le message d'erreur dit qu'elle était utilisée par un processus), il y avait mon exe en cours d'exécution. J'ai terminé la tâche, il était de retour à la normale après que