Chaque fois que j'ai essayé de copier 4 fichiers dans mon dossier bin, après avoir arrêté le service principal, un message d'erreur (TexteDll) s'affiche. 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. Lorsque j'ai cherché sur Google, j'ai constaté que le redémarrage du système pouvait 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’était l’explorateur qui bloquait la DLL compilée dans le dossier Debug ... Etrange, n’est-ce pas?
J'ai découvert en utilisant un outil appelé Unlocker.
Dû supprimer avec Unlocker, même quand il disait qu'il n'y avait pas de verrou sur le fichier et que je ne pouvais pas supprimer le dossier tant que je n'avais pas supprimé ce fichier ...
Après cela, il a compilé.
MODIFIER:
J'ai découvert pourquoi cela se produisait dans mon cas. J'avais la DLL ouverte dans un éditeur de texte à l'intérieur de Visual Studio ...
Parfois, lorsque vous double-cliquez sur un avertissement concernant la référence référencée La version d'assemblage ne correspond pas entre deux projets ou plus que vous avez oublié de fermer Fermez la fenêtre de la vue d'assemblage et elle y reste entre d'autres l’assemblée étant verrouillée par VS elle-même et il m’a fallu beaucoup de temps pour comprendre cela :)
Soyez prudent avec le pouvoir fourni par VS;)
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 bin, le dossier de publication du débogage et relancez Visual Studio Project.
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 un développeur et je n'aime pas les applications injectées dans la base de registre comme Unlocker . J'ai utilisé SysInternals Process Explorer quel processus a verrouillé mon dll Find > Find Handle or Dll [Ctrl-F]
et a tué le processus.
D'autres ont déjà établi que cette erreur était due à une autre application bloquant le fichier. Je voulais simplement souligner que git diff
verrouille également les fichiers jusqu'à ce que vous en sortiez. C'est ce qui a causé cela dans mon cas.
Dans mon cas, je devais tuer un processus suspendu MSBuild.exe
qui bloquait le fichier (il existait même après la fermeture de Visual Studio).
Utilisez-vous un logiciel anti-virus? Il est possible que le logiciel audiovisuel (ou un autre logiciel) lisait le fichier à l'aide des API de mappage de fichier à l'origine du problème.
J'ai eu le même problème. Redémarrer n'a pas fonctionné pour moi. Un processus appelé VBSCompiler était en cours d'exécution dans le gestionnaire de tâches. J'ai dû mettre fin au processus pour corriger cette erreur.
La solution pour moi était de fermer toutes les instances de VS et de supprimer tous les processus devenv.exe suspendus.
Aucune des solutions affichées ici ne fonctionnait pour moi. C'était devenv.exe (Visual Studio) verrouiller le fichier, mais si je le redémarrais, le verrouillerait à nouveau.
Bizarrement, Windows ne m'a pas laissé supprimer les fichiers (dans la Corbeille), mais Maj + Suppr (suppression définitive) fonctionnait.
J'ai eu le même problème. Comment j'ai résolu le problème:
Supprimer le dossier obj et reconstruire a fonctionné pour moi
Fermez Visual Studio et exécutez-le en tant qu'administrateur. C'est réglé mon problème.
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. Arrêter et exclure le répertoire de mon logiciel antivirus et fermer Visual Studio semble fonctionner.
La solution pour moi était de redémarrer l'ordinateur.
dans mon cas, supprimé le dossier obj dans la racine du projet et reconstruire le projet a résolu mon problème !!!
Il a été signalé en 2016 par Andrew Cuthbert que git diff verrouille également les fichiers jusqu'à ce que vous en sortiez.
Ce ne sera pas le cas avec Git 2.23 (T3 2019)
Voir commit 3aef54e (11 juil. 2019) par Johannes Schindelin (dscho
) .
(Fusionné par Junio C Hamano - gitster
- dans commit d9beb46 , 25 juillet 2019)
diff
:munmap()
contenu du fichier avant d'exécuter diff externeLorsque vous exécutez un diff externe à partir, par exemple, d'un
diff tool
, il est prudent de supposer que nous voulons écrire les fichiers en question.
Sous Windows, cela signifie qu’il ne peut y avoir aucun autre processus contenant un descripteur ouvert pour ces fichiers, ni même une région mappée.Donc, assurons-nous que
git diff
lui-même ne contient aucun descripteur ouvert pour les fichiers en question.En fait, nous allons simplement libérer la paire de fichiers tout de suite, 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
J'ai aussi eu la même erreur aujourd'hui. J'ai résolu ce problème en reconstruisant le projet.
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 et puis j'ai pu compiler à nouveau.
S'il s'agit d'une application Web, supprimer des fichiers du dossier Temporary ASP.NET Files pourrait être une solution.
Si vous utilisez des profileurs tels que 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 publiait le fichier après un certain temps, mais je ne pouvais pas, à vie, dire en quoi consistait ce délai. Semble être aléatoire
J'ai eu cette erreur causée par un fichier «plus» vs en question en cours d'exécution dans une autre console. Oops.