L'opération demandée ne peut pas être effectuée sur un fichier avec une section mappée par l'utilisateur ouverte

Chaque fois que j'ai essayé de copier 4 fichiers dans mon dossier bin, après avoir arrêté le service principal, je reçois une erreur avec un fichier (TexteDll). L'erreur est:

Cannot copy TexteDll: The requested operation cannot be performed on a file 
with a user-mapped section open

Cela peut être dû à un verrouillage du système. Ou peut-être qu'un autre processus utilise cette DLL. Quand j'ai googlé, j'ai trouvé que le redémarrage du système peut résoudre ce problème.

Quelqu'un peut-il suggérer une cause ou une solution à cela? J'ai inspecté les propriétés de TexteDll (général, version, sécurité, etc.). Tout semble normal.

Dans mon cas, c'est l'Explorateur qui verrouillait la DLL qui a été compilée dans le dossier Debug ... Étrange, n'est-ce pas?

J'ai découvert en utilisant un outil appelé Unlocker.

J'ai dû supprimer avec Unlocker, même quand il disait qu'il n'y avait pas de verrou sur le fichier, et je ne pouvais pas supprimer le dossier tant que je n'avais pas supprimé ce fichier unique ...

Après cela, il a compilé.

ÉDITER:

J'ai découvert pourquoi, dans mon cas, cela se produisait. J'ai fait ouvrir la DLL dans un éditeur de texte dans Visual Studio ...

• Parfois, lorsque vous double-cliquez sur un avertissement concernant la non-correspondance de la version de l'assembly référencé entre deux ou plusieurs projets, vous oubliez de fermer la fenêtre de la vue de l'assembly et elle y reste parmi d'autres onglets ... vous vous retrouvez donc avec l'assembly verrouillé par VS lui-même et il m'a fallu beaucoup de temps pour comprendre cela :)

  Soyez prudent avec la puissance fournie par VS;)

• Un autre scénario fictif. Parfois, il suffit de supprimer tout le dossier obj ou simplement le fichier averti car celui verrouillé aide à cette erreur de merde.

fermez tous les documents sur VS et essayez de reconstruire à nouveau. Si cela ne fonctionne pas, redémarrez VS. Ce problème est lié au verrouillage des fichiers DLL.

Fermez Visual Studio, supprimez le bac, déboguez le dossier des versions et redémarrez le projet Visual Studio. qui a résolu mon problème

J'ai eu le même problème et dans mon cas, il est apparu que le fichier de sortie existant était verrouillé par une autre application.

Vous pouvez vérifier quelle application verrouille votre fichier de sortie avec OpenedFilesView: http://www.nirsoft.net/utils/opened_files_view.html

Je suis développeur et je n'aime pas les applications injectées dans Registery comme Unlocker. J'ai utilisé SysInternals Process Explorer, lequel processus a verrouillé ma DLL Find > Find Handle or Dll [Ctrl-F]et a tué le processus.

D'autres ont déjà établi que cette erreur est due à une autre application ayant un verrou sur le fichier. Je voulais juste souligner que cela git diffverrouille également les fichiers jusqu'à ce que vous quittiez. C'est ce qui a causé cela dans mon cas.

J'ai eu le même problème. Comment je l'ai résolu:

1. Ouvrez le "Gestionnaire des tâches"
2. Fin de la tâche "Explorer.exe"
3. Cliquez sur "Fichier" -> Créer une nouvelle tâche - Tapez "explorer.exe" -> OK
4. Nettoyer mon projet et ça marche

Utilisez-vous un logiciel antivirus. Il est possible que le logiciel AV (ou un autre logiciel) ait lu le fichier à l'aide des API de mappage de fichiers qui ont causé le problème.

Dans mon cas, j'ai dû tuer un MSBuild.exeprocessus suspendu qui bloquait le fichier (il était là même après avoir fermé Visual Studio).

La suppression du dossier obj et la reconstruction ont fonctionné pour moi

J'ai eu le même problème. Le redémarrage n'a pas fonctionné pour moi. Il y avait un processus appelé VBSCompiler en cours d'exécution dans le gestionnaire de tâches. J'ai dû mettre fin au processus pour corriger cette erreur.

Aucune des solutions affichées ici n'a fonctionné pour moi. C'était devenv.exe (Visual Studio) verrouillant le fichier, mais si je le redémarrais, il le reverrouillerait.

Bizarrement, Windows ne me laissait pas supprimer les fichiers (dans la corbeille), mais Shift + Delete (suppression permanente) fonctionnait.

Fermez Visual Studio et exécutez-le en tant qu'administrateur. Il a résolu mon problème.

La solution pour moi était de fermer toutes les instances de VS et de tuer tous les processus devenv.exe suspendus.

La solution pour moi était de redémarrer l'ordinateur.

Il a été souligné en 2016 par Andrew Cuthbert que git diff verrouille également les fichiers jusqu'à ce que vous en quittiez.

Ce ne sera pas le cas avec Git 2.23 (Q3 2019)

Voir commit 3aef54e (11 juil.2019 ) de Johannes Schindelin ( dscho) .
^{(Fusionné par Junio ​​C Hamano - gitster- en commit d9beb46 , 25 juil.2019 )}

diff: munmap() contenu du fichier avant d'exécuter un diff externe

Lors de l'exécution d'un diff externe de, disons, a diff tool, il est sûr de supposer que nous voulons écrire les fichiers en question.
Sous Windows, cela signifie qu'il ne peut y avoir aucun autre processus tenant une poignée ouverte sur lesdits fichiers, ou même juste une région mappée.

Alors assurons-nous que git diff lui même ne détient aucune poignée ouverte sur les fichiers en question.

En fait, nous allons simplement publier la paire de fichiers immédiatement, car le diff externe utilise les fichiers que nous venons d'écrire, nous n'avons donc plus besoin de conserver le contenu du fichier en mémoire.

Cela corrige git-for-windows # 1315

Je voyais ces erreurs lors de la création d'applications Dot Net avec Ant.

Dans mon cas, il s'agissait de notre logiciel de sauvegarde d'entreprise, l'agent Symantec DLO. L'arrêter et exclure le répertoire de mon logiciel antivirus et fermer Visual Studio semble fonctionner.

dans mon cas, supprimé le dossier obj dans la racine du projet et le projet de reconstruction a résolu mon problème !!!

J'ai rencontré cette erreur et il s'est avéré que le problème était que FxCop s'exécutait sur mon projet. J'ai fermé FxCop puis j'ai pu compiler à nouveau.

S'il s'agit d'une application Web, la suppression de fichiers dans le dossier Fichiers ASP.NET temporaires peut être une solution.

Si vous utilisez des profileurs comme AQ Time, ceux-ci peuvent également verrouiller le fichier. La solution dans ce cas serait de redémarrer le profileur ou simplement de décharger / charger l'ensemble en question du profileur. Pour AQ Time, j'ai remarqué qu'il libérait le fichier après un certain temps, mais je ne peux pas pour la vie de moi dire ce qu'est ce délai. Semble être aléatoire

J'ai aussi eu la même erreur aujourd'hui. J'ai résolu ce problème en reconstruisant le projet.

J'ai eu cette erreur causée par un fichier vs plus en question laissé en cours d'exécution dans une autre console. Oups.

Aucune des réponses ci-dessus n'a résolu ce problème.

Quelqu'un avait un projet dans ma solution configuré pour utiliser un processeur x64 dans la configuration de construction. Le changer en Any CPU a amené la génération à utiliser un nouveau dossier. Je ne sais toujours pas quel processus avait (a) un verrou sur ce fichier.

J'ai eu ce même problème. J'ai supprimé la DLL du dossier temporaire, supprimé l'accès en lecture seule et redémarré la machine et l'ai fait fonctionner.

Dans mon cas, je ferme simplement toutes les instances et copie mon dossier d'application racine et le colle dans un emplacement différent, puis ouvre la solution dans VS ça fonctionne ....

Mon problème a également été résolu en passant au crible l'Explorateur de processus. Cependant, le processus que j'ai dû tuer était le MySQL Notifier.exe qui était toujours en cours d'exécution après la fermeture de toutes les applications VS et SQL.