Impossible de copier le fichier, l'accès au chemin est refusé
J'utilise visual studio 2005 après avoir pris le code de l'application de contrôle de version pour la première fois correctement, mais après quelques modifications, une erreur de ce type est générée lors de la compilation.
Erreur 383 Impossible de copier le fichier "..\root\leaf\Bin\Debug\test.Resources.xml" dans "Bin\Debug\test.Resources.xml". L'accès au chemin 'Bin\Debug\test.Resources.xml' est nié. li.rollmodel
Quelqu'un sait-il pourquoi ce problème se pose?
Éditer Je vois que le dossier physique complet du code source de mon projet est en lecture seule. Je ne peux pas supprimer cette propriété en lecture seule.
Tout d'abord, n'importe quel corps me dit comment supprimer la propriété en lecture seule d'un dossier que j'ai supprimé, mais montrant toujours celui-là, j'ai essayé du côté du contrôle de version également, mais avec le même effet.
J'ai résolu ce problème en supprimant les fichiers litigieux du dossier bin et en reconstruisant le projet.
Assurez-vous simplement que le dossier n'est pas en lecture seule et reconstruisez la solution.
J'ai résolu ce problème: Fermez Visual Studio, rouvrez-le et chargez la solution, Reconstruisez votre solution Mon problème est survenu avec TFS et Visual Studio 2010.
Kill processus VBCSCompiler.exe et reconstruire.
Je suis entré dans ce problème aussi.
Commencez par vérifier si vous avez mappé vos dossiers bin et obj sur le programme de contrôle de source.
Il peut s’agir de transformer vos fichiers de dossiers binaires en archives en lecture seule, ce qui empêche Visual Studio de les écraser lors de la compilation du code.
Allez supprimer le mappage de ces dossiers, vérifiez les modifications et essayez à nouveau.
Mon problème est survenu avec TFS (Team Foundation Server) et Visual Studio 2010.
J'espère que ça aide quelqu'un.
Exécutez votre Visual Studio en tant qu'administrateur
J'utilise Visual Studio 2013. J'ai rencontré ce problème 2 fois:
À la première occasion, j'utilisais Visual Studio sans droits d'administrateur. J'ai donc fermé VS et commencé en utilisant l'option ' Exécuter en tant qu'administrateur '. Cela a résolu mon problème.
La deuxième fois, j'ai redémarré VS plusieurs fois, chaque fois en m'assurant de l'exécuter en tant qu'administrateur. De plus, j'ai reconstruit la solution plusieurs fois. Mais malgré cela, j'ai eu une erreur. Après cela, j'ai supprimé le fichier concerné de l'emplacement cible (le fichier était déjà présent peut être de la construction précédente à l'emplacement où il tente de copier) et reconstruit la solution . Après cela, l'erreur est partie et tout s'est bien passé!
Cela a de nouveau fait saillie dans Visual Studio 2017. Dans ce cas, la cause en est le processus Service Insights ServiceHub.DataWarehouseHost.exe.
Il existe une solution de contournement dans le fil avertissement MSB3026: impossible de copier "obj\Debug\netcoreapp1.1\src.pdb" dans "bin\Debug\netcoreapp1.1\src.pdb" , ce qui est à ajouter un événement de pré-génération du projet pour tuer le processus à chaque construction du projet. Citant de ce lien:
- Clic droit sur les propriétés du projet
- Choisissez des propriétés
- Construire des événements
- Ligne de commande d'événement pré-construction
taskkill /IM ServiceHub.DataWarehouseHost.exe /F 2>nul 1>nul
Exit 0
- Sauvegarder et construire
Dans mon cas, c'est l'antivirus qui a bloqué le fichier.
Quelqu'un peut-il savoir pourquoi ce problème se pose?
En regardant votre réponse indiquant que vous avez résolu votre problème par une copie manuelle, je dirais que le code sur lequel vous travailliez a été créé par un autre utilisateur (avec les privilèges d'administrateur également), de sorte qu'il vous était verrouillé. En effectuant copie -? coller, vous avez fait votre propre copie de la source avec tous les accès nécessaires. La seule chose à noter est que, dans ce cas, si cet autre développeur doit travailler sur votre copie, il/elle sautera dans le même problème que vous aviez auparavant.
J'ai rajouté toutes mes dépendances/références non.NET et cela a fonctionné.
Avait le même problème, mais redémarrer Visual Studio à chaque fois n'était pas une option pour moi, car le problème se produit parfois très souvent.
Je l’ai traitée en installant Unlocker (tente d’installer une barre d’outils lors de l’installation, alors n’oubliez pas de décocher cette), cette application me donne un accès rapide pour renommer supprimer un fichier ".xml" verrouillé. Je sais que cela n’est qu’une solution de contournement également, mais pour moi, c’était la solution la plus rapide pour résoudre ce problème.
J'ai aussi eu le même problème. J'ai eu des messages d'erreur liés à ne peut pas copier depuis l'accès au chemin refusé. Dans mon cas, tous mes fichiers DLL et XML, etc., sont placés dans le dossier D:\TFS\Example\Bin\Debug.
J'ai cliqué avec le bouton droit sur le dossier Bin, cliqué sur Propriétés et constaté que la case à cocher en lecture seule est cochée sous Attributs.
J'ai décoché la case à cocher Lecture seule et cliqué sur Appliquer, puis sur OK dans la nouvelle fenêtre contextuelle affichée.
Je suis retourné à Visual Studio et ai construit ma solution qui me donnait des messages d'erreur.
Voilà .. Cette fois, il construit avec succès sans erreurs.
Je ne sais pas si c'est parfait, mais je l'ai fait pour résoudre mon problème.
J'ai créé ce problème lorsque j'ai ajouté un nouveau projet d'installation à la solution, puis j'ai ajouté des fichiers directement à partir du dossier/bin/release du projet d'application principal dans le dossier des fichiers d'application du projet d'installation. Le contrôle de la source du projet d'installation m'empêchait constamment de terminer la construction du projet principal.
Solution: créez un dossier de vidage distinct en dehors de tout projet contenant tous les fichiers à inclure dans l'installation, puis ajoutez-les à partir de celui-ci. C'est pénible car je dois maintenant me rappeler de copier tous les fichiers pour chaque nouveau paquet d'installation. Je pourrais voir si je pouvais faire quelque chose avec les actions post-build: notre build automatisé pour rendre le processus plus fluide.
Si vous copiez des fichiers dans une solution, assurez-vous qu'ils ne sont pas en mode lecture seule. Faites un clic droit sur le fichier et décochez l'option d'attribut pour résoudre mon problème.
Vérifiez le Gestionnaire des tâches et assurez-vous de ne pas suspendre un processus devenv.exe. Tuez le processus de fuite et réessayez.
J'ai résolu ce problème moi-même. Le problème était que j'avais la solution ouverte dans un autre endroit. Après la fermeture ça marche
J'ai eu la même erreur mais j'utilise Perforce contrôle de version. Voici comment je l'ai corrigé.
- Fermé Perforce P4V client
- Visual Studio 2010 redémarré (peut-être pas nécessaire)
- Reconstruit le projet qui a réussi
- Senti exceptionnellement heureux et dégoûté en même temps
Old Post, mais ce zombie frappe VS 2017 (je n'ai pas cherché à comprendre pourquoi il ne s'agit que de "certains" projets). Dans ce cas, il ne s'agit pas de autorisations utilisateur, mais du processus IIS Express qui utilise toujours les fichiers.
Vous verrez l'icône dans votre barre des tâches 
- Clic-droit
- Sortie
- Vous devriez pouvoir
rebuildsans ce message ennuyeux "autorisation refusée".
C’est aussi pourquoi le "redémarrage de Visual Studio" corrigera le problème. Ce faisant, arrête IIS Express.
Hth ...
Juste un clic droit sur votre projet MVC et cliquez sur l'option nettoyer. J'ai eu un problème similaire et le nettoyage du projet avant la reconstruction l'a résolu pour moi.
J'ai pu résoudre le problème en supprimant le fichier cible qui se plaint (dans votre exemple, "Bin\Debug\test.Resources.xml") du dossier bin du site Web cible et en le reconstruisant.C'est corrigé pour moi.
1) fermer la solution visual studio
2) naviguez jusqu'à la commande Invite -> exécuter en tant qu'administrateur -> iisreset/stop
3) accédez à c -> Windows -> Microsoft.Net -> Framework64 -> v4.030319 -> Fichiers Asp.NET temporaires -> Supprimez tous les fichiers et dossiers de ce chemin.
4) Revenir à la commande Invite -> iisreset/start
5) Ouvrez maintenant le studio visuel -> exécuté en tant qu'administrateur -> nettoyez la solution et générez-la (ne reconstruisez pas ... la compilation n'a fonctionné que pour moi)
J'ai eu aussi le même problème. Je l'ai corrigé en décochant les propriétés en lecture seule du dossier racine.
J'ai aussi eu ce problème. Voici comment est résolu ce
- Exclure le dossier
bindu projet. - Fermer studio visuel.
- Nettoyage du disque du lecteur C.
- Ré-ouvrir le projet dans Visual Studio.
- Et ensuite reconstruire la solution.
- Exécuter le projet.
Ce processus fonctionne pour moi.
Allez au chemin du fichier puis décochez la case en lecture seule de ce fichier.
Assurez-vous d’ajouter le nom du fichier après le nom du chemin (chemin\nomFichier.extension). J'ai passé plus d'une heure sans noter ceci.
J'ai rencontré ce problème plusieurs fois et la solution que j'ai trouvée consiste à supprimer le dossier de débogage, puis à reconstruire votre solution/projet. Travaillé pour moi !!
Dans mon cas, j'ai transféré un projet de Windows vers OSX à l'aide de Visual Studio Community 7.1.5 pour Mac. En quoi l’astuce a-t-elle été de désactiver l’option Use MSBuild engine (recommended for this type of project) dans les préférences du projet:
Vous n'êtes pas censé changer l'attribut de dossier en not-readonly . La raison pour laquelle vous voyez ce message d'erreur est que le contrôle de source suppose que vous stockez uniquement vos fichiers divers ailleurs que le dossier bin, car il est réservé aux fichiers .Net sont automatiquement créés par .Net et ne veulent pas les ajouter au contrôle de source.
Je suggère au lieu d'utiliser Environment.CurrectDirectory (que je suppose que vous utilisez actuellement), vous créez un dossier nommé "MyProjectName" dans% appdata% address, puis utilisez:
System.IO.Path.Combine(Environment.GetEnvironmentVariable("appdata"),"YourProjectName").
Tout d'abord, allez à l'emplacement du fichier. Cliquez ensuite avec le bouton droit de la souris sur le dossier du fichier -> Propriétés -> Option en lecture seule décochée et appliquez-la aux fichiers et à ses sous-dossiers . Il a résolu mon problème .._. Bon codage!
Effacez toutes les bibliothèques référencées dans "bin\debug" et cliquez avec le bouton droit de la souris sur Solution dans Solution Explorer, puis cliquez sur "Nettoyer la solution".
Et reconstruire !!
Pour moi, le problème était qu'un autre projet de la solution contenait le même fichier .dll qui avait été archivé plus récemment.
La copie manuelle de la version la plus récemment archivée du fichier .dll de l'autre dossier bin du projet vers le dossier bin du projet générant l'erreur a résolu le problème.
Un correctif à plus long terme pour notre solution serait d’utiliser le même fichier .dll pour tous les projets de la solution au lieu d’avoir le même fichier .dll dans plusieurs projets, mais je n’avais pas envie de le résoudre, alors la solution rapide était juste de copier sur la version la plus récente.
Changer le chemin de sortie a fonctionné pour moi dans Visual Studio 2015. Cela devrait aider - Changer le répertoire de sortie de la construction
Donc, je viens de rencontrer le même problème, la cause qui m'est due: mon dossier de développement a été partagé afin que je puisse utiliser un mac comme hôte de compilation pour une application IOS utilisant Xamarin. Le projet fonctionnait sur mac, qui a pris possession de la dll. Par conséquent, je ne pouvais pas modifier cette dll de nulle part ailleurs. En arrêtant simplement l'application sur le Mac, je suis redevenu propriétaire, ce qui a permis un accès complet à nouveau. J'espère que cela fait depuis.
Je sais que c’est un vieux fil conducteur, mais pour ceux qui cherchent des réponses, comme moi il ya quelques minutes, je recommande d’essayer de redémarrer votre ordinateur au préalable. Ce seul réparé pour moi. Avant ne pouvait même pas copier manuellement dans le dossier.
J'ai essayé de me déconnecter et de me reconnecter et cela a fonctionné pour moi. J'espère que cela aidera quelqu'un d'autre.
Cela peut être un étrange sous-produit du chargement de la source initialement à partir du contrôle de source (TFS, etc.) où tous les fichiers et dossiers sont protégés en écriture. Accédez au répertoire de niveau supérieur et vérifiez les propriétés. Vous pouvez également trouver l'attribut Lecture seule vérifié. Décochez cette case et le système devrait vous demander si vous souhaitez que tous les répertoires du niveau supérieur soient configurés en écriture. Cela devrait résoudre le problème.
Solution simple:
Il suffit de mettre à jour les paquets suivants
Microsoft.CodeDom.Providers.DotNetCompilerPlatform v1.0.5 to v1.0.7
Cela résoudra le problème.