Impossible de copier le fichier reference.dll dans bin/reference.dll. Le processus ne peut pas accéder au fichier reference.dll car il est utilisé par un autre processus
Pour l'une de mes applications ASP.NET 3.5, chaque fois que j'essaie de générer l'application Web, les erreurs de génération suivantes sont générées dans Visual Studio 2008:
Erreur 165 Impossible de copier le fichier "C:\InOne\Common\DexProcessor\bin\Debug\DexProcessor.dll" dans "bin\DexProcessor.dll". Le processus ne peut pas accéder au fichier 'bin\DexProcessor.dll' car il est utilisé par un autre processus. InVision2 Erreur 166 Impossible de copier le fichier "C:\InOne\Common\DexParser\bin\Debug\InOne.DexParser.dll" dans "bin\InOne.DexParser.dll". Le processus ne peut pas accéder au fichier 'bin\InOne.DexParser.dll' car il est utilisé par un autre processus. InVision2 Erreur 167 Impossible de copier le fichier "C:\InOne\Common\AlertProcessor\bin\Debug\InOne.Invision.AlertProcessing.dll" dans "bin\InOne.Invision.AlertProcessing.dll". Le processus ne peut pas accéder au fichier 'bin\InOne.Invision.AlertProcessing.dll' car il est utilisé par un autre processus. InVision2 Erreur 168 Impossible de copier le fichier "C:\InOne\Common\InVision.BusinessLogic\bin\Debug\InVision.BusinessLogic.dll" dans "bin\InVision.BusinessLogic.dll". Le processus ne peut pas accéder au fichier 'bin\InVision.BusinessLogic.dll' car il est utilisé par un autre processus. InVision2 Erreur 169 Impossible de copier le fichier "C:\InOne\Common\InVision.Common\bin\Debug\InVision.Common.dll" dans "bin\InVision.Common.dll". Le processus ne peut pas accéder au fichier 'bin\InVision.Common.dll' car il est utilisé par un autre processus. InVision2 Erreur 170 Impossible de copier le fichier "C:\InOne\Data\bin\Debug\InVision.Data.dll" dans "bin\InVision.Data.dll". Le processus ne peut pas accéder au fichier 'bin\InVision.Data.dll' car il est utilisé par un autre processus. InVision2 Erreur 171 Impossible de copier le fichier "C:\InOne\Common\InVision.DataAccessLayer\bin\Debug\InVision.DataAccessLayer.dll" dans "bin\InVision.DataAccessLayer.dll". Le processus ne peut pas accéder au fichier 'bin\InVision.DataAccessLayer.dll' car il est utilisé par un autre processus. InVision2 Erreur 172 Impossible de copier le fichier "C:\InOne\Common\InVision.DataAccessLayer.SqlClient\bin\Debug\InVision.DataAccessLayer.SqlClient.dll" dans "bin\InVision.DataAccessLayer.SqlClient.dll". Le processus ne peut pas accéder au fichier 'bin\InVision.DataAccessLayer.SqlClient.dll' car il est utilisé par un autre processus. InVision2
Cela a commencé à se produire il y a une semaine et est très ennuyeux ... Je dois aller dans le dossier bin de l'application Web et supprimer les fichiers pdb, ce qui me permettra ensuite de supprimer les dll la plupart du temps. De temps en temps, cela ne me laisse pas; je dois donc fermer Visual Studio, puis me permettre de les supprimer. J'ai vérifié et c'est Visual Studio (devenv) qui verrouille les dll. Le redémarrage de la machine n’aide en rien.
Cela réduit vraiment ma productivité. Y a-t-il quelque chose que je puisse faire pour résoudre ce problème?
Comme mentionné précédemment, Visual Studio 2008 (devenv.exe) est le processus de verrouillage des DLL.
J'ai remarqué quelque chose ... Une fois la compilation réussie, toutes les DLL sont copiées dans le dossier bin, elles sont toutes supprimées, puis un nouvel ensemble est copié dans le bac. Lorsqu'il échoue, le premier ensemble de DLL est copié, puis il échoue. Donc, il semble utiliser le dossier bin pour 2 choses alors qu'il ne devrait l'être que pour 1. Est-ce que cela vous aide?
Le problème a fini par être que dans le web.config quelqu'un avait ajouté:
hostingEnvironment shadowCopyBinAssemblies="false"
Après avoir commenté cela, tout a commencé à bien construire. Quel cauchemard!!
Utilisez ProcessExplorer pour recherchez le processus d'ouverture du fichier et continuez à partir de là.
Si un processus utilise actuellement ces DLL, vous ne pouvez pas le supprimer et le réécrire. Vous devrez arrêter ou arrêter le processus à l'aide de ces DLL pendant la compilation.
Je me bats ce problème depuis des années!
Avez-vous essayé d'ajouter ceci à votre événement PREBUILD?
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
Voir ceci pour plus d’informations: http://nayyeri.net/file-lock-issue-in-visual-studio-when-building-a-project
Voici un autre fil, avec plus de choses à essayer ...
Ce qui a fonctionné pour moi, c'est l'événement de pré-construction suivant:
if exist "$(TargetPath).locked.bak" del "$(TargetPath).locked.bak"
if exist "$(TargetPath).bak" del "$(TargetPath).bak"
if exist "$(TargetPath).locked" ren "$(TargetPath).locked" "$(TargetFileName).locked.bak"
if exist "$(TargetPath)" ren "$(TargetPath)" "$(TargetFileName).bak"
Ce que j'ai remarqué dans mon cas, c'est que les 2 fichiers sont en cours de création et ne peuvent pas être supprimés. Vous pouvez cependant les renommer (et ils sont toujours utilisés si vous essayez de les supprimer). Lors d’une prochaine construction, les fichiers renommés ne sont plus utilisés (verrou supprimé) et ils peuvent être supprimés. C’est ce que fait le script ci-dessus, après quoi il peut renommer en toute sécurité les nouveaux fichiers verrouillés de manière à éviter tout problème de génération du fichier. construire la sortie.
Les autres événements de pré-construction publiés ici et ailleurs ne m'ont pas beaucoup aidé (ils n'ont travaillé que pour une version supplémentaire ou seulement quelques-unes avant que le problème ne se pose à nouveau). Alors maintenant, j'utilise celui posté ci-dessus pour mes besoins de débogage.
Malheureusement, je n'ai pas eu de chance avec les événements de pré-construction. Ce qui a fonctionné, à la manière typique de IT Crowd, était de quitter Visual Studio et de le rouvrir.
Je voulais juste dire que ce problème a commencé avec moi aujourd'hui. (VS 2010, C #) Je travaille sur ce programme depuis un mois sans ce problème, maintenant, aujourd'hui, il a commencé. Je commence VS, change le code, compile et teste et quitte le programme. Apportez une autre modification, compilez et entrez dans le fichier BOOM. Impossible de copier le fichier "obj\x86\Debug\progname.exe" dans "bin\Debug\progname.exe" car il est utilisé par un autre processus.
ProcExp affiche uniquement Visual Studio (en réalité devenv.exe) utilisant ce fichier. Une seule instance de VS est en cours d'exécution. Il existe deux listes sur mon debug\progname.exe, l'une est une DLL de type, l'autre est un handle de type.
L'utilisation de devenv/ResetSettings ne résout rien, mais 10 minutes perdues à tout remettre à ma vue souhaitée.
L'utilisation de l'astuce de renommer les événements PREBUILD mentionnée ci-dessus résout le problème pour quelques modifications, mais lors de la modification suivante, le fichier "exe.locked" est verrouillé et ne peut pas être supprimé. Ensuite, le changement de nom échoue.
Le nom de fichier debug\progname.exe reste verrouillé même après la fermeture du projet.
Fermez VS, supprimez manuellement les fichiers dans le dossier de débogage, ouvrez VS et ma solution, puis Build-> Clean Solution semble fonctionner pour moi, du moins cela fonctionne maintenant après que j'ai fait tout ce travail.
J'espère que cela aide - rwg
Si vous avez Visual Nunit, il doit verrouiller le fichier dll.
- Fermer VS
- Allez dans taks manager, tuez le processus Visual Nunit
- Maintenant ouvrez VS et construisez le projet
Solution facile pour Windows 7: Démarrez le service "Application Experience". Recherchez "Services" dans "Panneau de configuration".
-Martin
J'ai eu ce problème sur un projet Web avec System.Web.Extensions.dll à partir du dossier Assemblys de référence Microsoft. La définition de "Copy Local" sur false dans les propriétés de référence a corrigé le problème.
Bonjour, je suis confronté au même problème pendant un petit moment. C'est vraiment agaçant.
J'ai une solution plus simple mais pas si efficace au problème. Nettoyer le projet ou la solution résout le problème.
Allez simplement dans\Debug\bin et supprimez tous les fichiers .dll.
Travailler bien pour moi.
ouvrez votre projet dans l'explorateur cliquez sur la propriété du dossier bin et décochez la propriété en lecture seule que celle-ci fonctionne dans mon projet de formulaires xamarin
M'est arrivé tout à l'heure. Devait tuer tous les processus devenv.exe (il y en avait 3 après la fermeture de la fenêtre VS 2010).
Je suis aussi confronté à ce problème. J'essaye d'abord de supprimer contentious .dll mais cela indique l'accès refusé, puis je ferme mon VS et après ouverture, cela fonctionne bien.
Semblable à la réponse de Benoit mais ne nécessite aucune installation d’outil, vous pouvez utiliser la commande tasklist (gestionnaire de tâches) sur la ligne de commande avec le commutateur '/ m' pour obtenir une liste des processus utilisant la DLL:
tasklist/m mylocked.dll
J'ai vu des messages indiquant que vous devez le faire à partir du répertoire de la DLL en cause, mais je n'ai pas trouvé que ce soit le cas.
Ce problème se produit généralement lorsque vous modifiez votre projet d'un répertoire à un autre. Pour l’erreur de cliché instantané, vous avez peut-être ajouté cette ligne dans votre web.config.Pour résoudre ce problème, procédez comme suit:
Dans votre fichier web.config s'il y a quelque chose comme
<hostingEnvironment shadowCopyBinAssemblies="false" />
changer cela en
<hostingEnvironment shadowCopyBinAssemblies="true" />
ou l'enlever. Alors cela fonctionnera bien
Supprimer les lignes suivantes de mon app.config a résolu ce problème pour moi - j'utilise VS2010.
<runtime>
<assemblyBinding xmlns="urn:schemas-Microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="nunit.framework" publicKeyToken="96D09A1EB7F44A77" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-2.5.7.10213" newVersion="2.5.7.10213"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
Vous pouvez télécharger l'excellent SysInternals Handle programme. Cela vous indiquera quels processus verrouillent les fichiers concernés.
S'il s'agit d'un programme externe (par exemple, un scanner/indexeur de virus), cela devrait aider. S'il ne fait que signaler Visual Studio (devenv.exe) comme coupable, il sera alors moins utile!
Je suppose que vous savez déjà que c'est VS2008 qui verrouille les fichiers. Vous pouvez essayer d'exécuter MSBuild à partir de la ligne de commande et voir si les problèmes disparaissent. Malheureusement, Visual Studio peut garder les fichiers verrouillés comme il se doit, dans des scénarios difficiles à prévoir.
Cela m’arrive parfois lorsque j’utilise Visual Nunit pour les tests unitaires.
Il semble que le processus 'VisualNunitRunner.exe' verrouille les fichiers .dll dans le répertoire de destination.
J'ai utilisé Unlocker pour trouver le processus, le tuer ou déverrouiller les fichiers.
Supprimez les fichiers binaires du dossier bin\Debug et recompilez-les. Ça marche pour moi !!!
J'ai enfin comment le réparer. Cela se produit parce que le premier exe de débogage est toujours en cours d'exécution. Alors, allez dans le gestionnaire de tâches -> onglet Processus -> [votre nom de projet exe] et terminez le processus exe
vous pouvez également supprimer les dossiers bin et obj dans tous les projets de la solution, puis la reconstruire.
Le fichier ne peut pas être supprimé, heureusement peut être renommé et déplacé. J'ai donc créé un lot de pré-construction (en utilisant la date et l'heure comme chaîne aléatoire, il peut exister des moyens plus simples):
For /f "Tokens=2,3,4 Delims=/. " %%i In ("%Date%") Do @(
Set Month=%%i& Set Day=%%j& Set Year=%%k
)
set ActDate=%Year%-%Month%-%Day%
For /f "Tokens=1,2,3 Delims=/.:, " %%i In ("%Time%") Do @(
Set Hour=0%%i& Set Min=%%j& Set Sec=%%k
)
set ActTime=%Hour:~-2,2%-%Min%-%Sec%
move c:\MyProject\bin\Debug\myproject.exe c:\garbage\%ActDate%_%ActTime%_myproject.exe
Vérifiez si la DLL utilisateur et l'application référençant la DLL ciblent le même framework .NET . J'ai eu un cas où les frameworks étaient différents qui ont causé ce problème.
Il y avait un bogue spécifique dans Visual Studio 2008 qui a été corrigé dans SP1 qui pourrait être votre problème. Cela se produit lorsque vous référencez un fichier JavaScript incorporé et provoque le problème que vous voyez. Voir ici pour plus de détails.
J'avais un problème similaire et j'ai pu le résoudre en modifiant le fichier 'AssemblyInfo.cs'
J'utilisais Visual Studio 2012 lorsque cela a commencé avec une solution de 7 ans (pour la deuxième ou la troisième fois: je suis déjà venu à cette question).
J'ai essayé les différents vaudous. J'ai nettoyé la solution. N'a pas fonctionné J'ai redémarré Visual Studio. N'a pas fonctionné J'étais confiant que le dernier fonctionnerait, parce que c'est le vaudou qui a fonctionné la dernière fois.
En fin de compte, je me suis souvenu qu'une mise à jour de sécurité avait été installée la nuit dernière et qu'elle avait été configurée lorsque j'ai démarré ma machine ce matin - (connecté ou non? Aucune idée) - J'ai donc redémarré Windows et voilà, tout a fonctionné à merveille.
Merci MS pour plus d'esprit hacher.
Rencontré ce problème .. Sachez que je courais déjà le projet via git bash .. Je l'ai arrêté. Et maintenant, ça fonctionne bien.
Par conséquent, il est possible que vous exécutiez le même projet à partir de n’importe où dans votre section locale et que cette erreur se produise. Alors arrêtez ce programme et recommencez.
J'ai eu un problème similaire .___. Solution pour moi était de regarder le fichier * .csproj et sous j'ai trouvé le fichier manquant alors et ci-dessous était correct donc je viens de supprimer des lignes et cela a fonctionné immédiatement
Les verrous de fichiers font simplement partie de Visual Studio. Il n'y a pas de bons moyens de contourner ce problème.