Visual Studio "Impossible de copier" .... pendant la construction
Je continue à avoir cette erreur pendant la construction de mon projet VS2012 C #
Error 41 Could not copy "obj\Debug\WeinGartner.WeinCad.exe" to
"bin\Debug\WeinGartner.WeinCad.exe".
Exceeded retry count of 10. Failed.
Error 42 Unable to copy file "obj\Debug\WeinGartner.WeinCad.exe" to
"bin\Debug\WeinGartner.WeinCad.exe". The process cannot access the file
'bin\Debug\WeinGartner.WeinCad.exe' because it is being used by another
process.
Maintenant, j'ai compris que tuer le processus
Weingartner.WeinCad.vhost.exe
fonctionne (parfois) mais cela me met sur les nerfs. Un moyen d'empêcher que cela se produise?
Mes paramètres de débogueur sont
J'ai rencontré des messages d'erreur similaires dans Visual Studio 2013.
Surtout, j'ai constaté que cette situation s'est produite lorsqu'un processus de débogage a été arrêté à cause d'une exception.
Lorsque clean + build n'a pas résolu ce problème pour moi, j'ai eu du succès en procédant comme suit:
- Fermer Visual Studio
- Suppression des dossiers
binetobj, et - Réouverture de Visual Studio.
Ce "bogue" existe depuis Visual Studio 2003.
Enfin, j'ai également constaté que je pouvais souvent résoudre ce problème en renommant simplement le fichier exécutable, puis en le supprimant.
Dans Visual Studio Premium 2013 (mise à jour 3), j'ai résolu ce problème avec un one-liner pré-construit:
(if exist "$(TargetDir)*old.pdb" del "$(TargetDir)*old.pdb") & (if exist "$(TargetDir)*.pdb" ren "$(TargetDir)*.pdb" *.old.pdb)
Cela supprime gracieusement tous les anciens fichiers PDB (s’il le peut), puis renomme tout ce qui reste avec une extension .old.pdb. Un bel effet secondaire est que si l'ancien PDB est toujours verrouillé, il ajoute simplement un autre élément .old au nom du fichier. Ils seront tous nettoyés au prochain redémarrage de Visual Studio et lors de la génération.
Par exemple, la session de construction/débogage 1 laisse MyProject.pdb verrouillé.
La prochaine fois que vous construirez:MyProject.pdb -> MyProject.old.pdb
Ensuite, la session de construction/débogage 2 est lancée et les deuxMyProject.pdb et MyProject.old.pdb sont toujours verrouillés:MyProject.old.pdb -> MyProject.old.old.pdbMyProject.pdb -> MyProject.old.pdb
Enfin, le redémarrage de Visual Studio et une nouvelle construction élimineront ces deux problèmes et poursuivront le processus comme d'habitude.
C'est parce que vous avez fermé votre application, mais qu'elle fonctionne toujours en arrière-plan.
Solution temporaire:
- Aller au gestionnaire de tâches (Ctrl + Alt + Esc).
- Allez dans l'onglet Processus et trouvez "YourProjectName.exe".
- Cochez "Afficher les processus de tous les utilisateurs" si vous ne trouvez pas votre processus.
- Terminez le processus.
Solution permanente: vous devez fermer votre candidature par codage. Voici le code ...
System.Windows.Forms.Application.Exit();
Vous devez mettre ce code dans l'événement de clôture du formulaire sous toutes ses formes. Exemple:
private void frm_menu_FormClosing(object sender, FormClosingEventArgs e)
{
System.Windows.Forms.Application.Exit();
}
le fichier .vhost.exe est un processus de débogage. Il semble donc que le processus en cours de débogage ne se soit pas fermé correctement. Il y a des chances que vous ayez un bogue qui le garde en vie et n'arrête pas le processus de débogage correctement. Il existe des options pour se détacher du processus lorsque vous cliquez sur "Arrêter le débogage" au lieu de tuer le débogueur. Vous avez peut-être cet ensemble défini.
Mais c’est le problème: le fichier que vous essayez de copier est verrouillé (c’est-à-dire qu’il est toujours utilisé) par le système d’exploitation, ce qui empêche sa copie. Assurez-vous que le fichier est libre et que vous pourrez le copier.
Je l'ai résolu en tuant IISExpress dans le gestionnaire de tâches
Vous devez désactiver votre antivirus (surtout s'il s'agit d'un logiciel Avast) et réessayer. Ça m'a aidé. Le problème est que le débogueur/constructeur crée le fichier .exe identifié comme une menace par Avast et, par conséquent, supprimé juste avant de pouvoir être exécuté par VS.
J'ai pu résoudre ce problème (VS 2010) en fournissant les actions suivantes avant la construction;
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
Citation:
Une solution de contournement consiste à mettre cela dans la propriété de ligne de commande d'événement de pré-génération du> projet (dans l'onglet Evénements de construction):
Extrait de code
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
Exception
Dans certains cas, dans Visual Studio, lorsque vous (Build || Rebuild) au-dessus de en cours d'exécution IISExpress, vous êtes confronté à cette exception:
Impossible de copier fichier "obj\Debug\YourProjectName.dll" dans bin\YourProjectName.dll ". Le processus ne peut pas accéder le fichier 'bin\YourProjectName.dll' - car il est utilisé par un autre processus
Solution
- Faites un clic droit sur le projet Web à construire.
- Cliquez sur les propriétés.
- Sélectionnez l'onglet Événements de construction sur le côté gauche.
- Dans la ligne de commande d'événements de pré-construction, collez ces 2 lignes:
tasklist /fi "imagename eq iisexpress.exe" |find ":" > nul if errorlevel 1 taskkill /f /im "iisexpress.exe"
Vous êtes bon 2 GO!
Il semble qu'en changeant le nom de l'assembly d'un projet corrige le problème.
Donc au lieu de cela
Je le change en ceci
Notez que je viens de le changer de Increment and Recall à Increment_Recall, je viens de supprimer les espaces. Cela fonctionne maintenant très bien pour moi.
Tuer le processus w3wp.exe (IIS) résoudra souvent ce problème.
En général, vous pouvez connaître le processus qui verrouille le fichier en naviguant dans le dossier bin et en essayant de le supprimer. Le message d'erreur qui apparaîtra, au cas où un autre processus l'utilise, contiendra le nom du processus à tuer.
Ajouter dans l'événement de pré-construction de votre projet principal taskkill/f/fi "pid gt 0"/im "YourProcess.vshost.exe"
Je pense que je l'ai résolu en supprimant la coche à Break all processes when one process breaks dans les options de débogage (première capture d'écran-> deuxième option de l'op).
Ça fonctionne bien depuis un moment, depuis que je l'ai décochée.
J'utilise les contrôles MySql NET Connector et DevExpress dans mon projet. Peut-être que l'un d'entre eux ne disposait pas de connexions, de liaisons, etc., à cause de l'activation de ce drapeau.
EDITED: définitivement ça marche! Pas plus "Impossible de copier le fichier" et plus d'erreurs du concepteur de formulaire.
J'ai rencontré le même problème sur VS 2012 Version 11.0.60610.01 Update 3 sur Windows 8
Aucune fenêtre de concepteur n’était ouverte et le projet était une simple application console.
La suppression du processus vshost accédant au fichier ne fonctionne pas la plupart du temps, car le processus n’accède pas au fichier.
La solution de contournement la plus simple qui fonctionne et prend le moins de temps possible consiste à supprimer le projet de la solution, à créer un autre projet dans la solution, puis à ajouter l'original en arrière.
C'est un irritant et une perte de temps, mais c'est la moins chère de toutes les autres options que je connaisse.
J'espère que cela t'aides...
Ma contribution de 10 cents.
J'ai toujours ce problème de temps en temps sur VS 2015 Update 2.
J'ai trouvé que le changement de cible de compilation résout le problème.
Essayez ceci: si vous êtes dans DEBUG, passez à RELEASE et à build, puis revenez à DEBUG. Le problème est parti.
Stefano
Suivez les étapes ci-dessous
- Ouvrez le Gestionnaire des tâches (Ctrl + Alt + Suppr)
- Sous l'onglet Performances, sélectionnez <ProjectNameOfYours.exe>.
- Cliquez sur Terminer le processus.
- Maintenant construire la solution.
Les étapes ci-dessus ont résolu l'erreur de façon permanente :)
@ La réponse de Geoff ( https://stackoverflow.com/a/25251766/373954 ) est bonne, mais le code d'erreur 1 est renvoyé lors de la recompilation.
Voici ce qui a fonctionné pour moi (2> nul 1> nul à la fin + sortie 0):
(if exist "$(TargetDir)*old.pdb" del "$(TargetDir)*old.pdb") & (if exist "$(TargetDir)*.pdb" ren "$(TargetDir)*.pdb" *.old.pdb) 2>nul 1>nul
(if exist "$(TargetDir)*old.dll" del "$(TargetDir)*old.dll") & (if exist "$(TargetDir)*.dll" ren "$(TargetDir)*.dll" *.old.dll) 2>nul 1>nul
exit 0
Si aucune des réponses ne fonctionne, essayez cette vérification simple. Recherchez le fichier MSbuild.exe qui exécute votre projet au format EXE. Tuez MSBuild.exe et vous devriez être prêt à partir.
Je ne peux pas donner une solution pour empêcher cela, mais vous pouvez au moins RENOMMER le fichier verrouillé (Explorateur Windows ou fenêtre de commande classique), puis compiler/construire. Pas besoin de redémarrer ou de redémarrer VS201x. Avec un peu d’expérience, vous pouvez ajouter un script de pré-génération pour supprimer d’anciens fichiers ou le renommer en cas de blocage.
Si vous êtes débogage des modèles T4, cela se produit tout le temps. Ma solution (avant que MS ne corrige cela) serait simplement de tuer ce processus:
Gestionnaire des tâches -> Utilisateur -> T4VSHostProcess.exe
Ce processus n'apparaît que lorsque vous déboguez un modèle T4, pas lorsque vous en exécutez un.
- Ouvrir les propriétés du projet [menu> projet> propriétés]
- Choisissez l'onglet "debug"
- Décocher "Activer le processus d'hébergement de Visual Studio"
- Lancer le débogage [F5]
- Vous recevrez un avertissement de sécurité, juste "ok". Permet à l'application en cours d'exécution
- Arrêtez le débogage.
- Cochez l'option "Activer le processus d'hébergement de Visual Studio", sous l'onglet de débogage,
- Maintenant, essayez de démarrer le débogage, vous ne verrez plus d'erreur
[Travaille pour moi]
Voir cette autre réponse . Fondamentalement, vous pourriez avoir des processus MSBuild.exe s'exécutant en arrière-plan consommant des fichiers de ressources. Si vous avez des tâches antérieures ou postérieures à la génération qui entraînent le démarrage d'un MSBuild via une ligne de commande, essayez d'ajouter l'indicateur "/ nr: false" à cette commande. Mais encore une fois, voir la réponse précédente pour plus de détails.
J'ai remarqué des réponses qui ont résolu mon problème, MAIS, juste au cas où quelqu'un aurait le même problème que moi.
SI VOUS UTILISEZ UNE APP CONSOLE: AVANT DE FAIRE TOUT AUTRE.
Assurez-vous que toutes les fenêtres de la console ayant été ouvertes à partir d'une version précédente ont bien été fermées. Par exemple, je ne faisais que tester du code dans une application console. Je ne savais pas que la fenêtre de la console de l'une des précédentes exécutions de mon programme était ouverte. Au cours de cette session, j'étais en train de déboguer, la fenêtre a été poussée à l'arrière et je ne pouvais pas la voir. Cela dit, cela pourrait être votre problème, alors assurez-vous que ce n'est pas le problème.
Cette question était le premier résultat lors de la recherche de l'erreur suivante:
Impossible de copier le fichier "..." car il n'a pas été trouvé.
lors de la construction dans Visual Studio 2013 (mise à jour 3).
Solution: Désinstallation des "Outils de productivité pour productivité" dans Visual Studio 2013.
https://connect.Microsoft.com/VisualStudio/feedback/details/533411
Pour moi, c’est l’antivirus Avast qui ne laissera pas Visual Studio écrire/lire/exécuter un fichier. J'ai donc dû ajouter le dossier Visual studio 2010/2012 à la liste d'exclusion d'antivirus. Et juste après ce baam ... ça marche.
Assurez-vous que vous fermez toutes les instances wcfSvcHost et réessayez. Cela a fonctionné pour moi!
je travaille sur une solution de projets de micro-services où je dois exécuter deux projets en même temps, le conflit se produit lorsque la partie lunchsettings.json applicationurl: {portNo} pour les deux projets en cours est le même port.
lunchsettings.json pour le premier projet
...
"Project#1": {
...
"applicationUrl": "http://localhost:5001",
...
}
lunchsettings.json pour le deuxième projet
...
"Project#2": {
...
"applicationUrl": "http://localhost:5001",
...
}
pour le réparer
lunchsettings.json pour le premier projet
...
"Project#1": {
...
"applicationUrl": "http://localhost:5001",
...
}
lunchsettings.json pour le second projet
...
"Project#2": {
...
"applicationUrl": "http://localhost:5002",
...
}
J'ai enfin comment le réparer. Pourquoi nous ne pouvons pas continuer le débogage après le premier débogage parce que le premier exe de débogage est toujours en cours d'exécution. Ainsi, après le premier débogage, vous devez accéder au gestionnaire de tâches -> onglet Processus -> [exe de votre nom de projet] et terminer le processus exe.
ça marche pour moi :)
Voici un script pour se débarrasser définitivement de ce problème:
REM This script is invoked before compiling an Assembly, and if the target file exist, it moves it to a temporary location
REM The file-move works even if the existing Assembly file is currently locked-by/in-use-in any process.
REM This way we can be sure that the compilation won't end up claiming the Assembly cannot be erased!
echo PreBuildEvents
echo $(TargetPath) is %1
echo $(TargetFileName) is %2
echo $(TargetDir) is %3
echo $(TargetName) is %4
set dir=C:\temp\LockedAssemblies
if not exist %dir% (mkdir %dir%)
REM delete all assemblies moved not really locked by a process
del "%dir%\*" /q
REM Assembly file (.exe / .dll) - .pdb file and eventually .xml file (documentation) are concerned
REM use %random% to let coexists several process that hold several versions of locked assemblies
if exist "%1" move "%1" "%dir%\%2.locked.%random%"
if exist "%3%4.pdb" move "%3%4.pdb" "%dir%\%4.pdb.locked%random%"
if exist "%3%4.xml.locked" del "%dir%\%4.xml.locked%random%"
REM Code with Macros
REM if exist "$(TargetPath)" move "$(TargetPath)" "C:\temp\LockedAssemblies\$(TargetFileName).locked.%random%"
REM if exist "$(TargetDir)$(TargetName).pdb" move "C:\temp\LockedAssemblies\$(TargetName).pdb" "$(TargetDir)$(TargetName).pdb.locked%random%"
REM if exist "$(TargetDir)$(TargetName).xml.locked" del "C:\temp\LockedAssemblies\$(TargetName).xml.locked%random%"
REM PreBuildEvent code
REM $(SolutionDir)\BuildProcess\PreBuildEvents.bat "$(TargetPath)" "$(TargetFileName)" "$(TargetDir)" "$(TargetName)"
REM References:
REM http://www.hanselman.com/blog/ManagingMultipleConfigurationFileEnvironmentsWithPreBuildEvents.aspx
REM http://stackoverflow.com/a/2738456/27194
REM http://stackoverflow.com/a/35800302/27194
Le script doit être appelé à partir de chaque événement de pré-génération de projet VS.
$(SolutionDir)\BuildProcess\PreBuildEvents.bat "$(TargetPath)" "$(TargetFileName)" "$(TargetDir)" "$(TargetName)"
Tuer le processus vstest.executionengine.exe résout ce problème 90% du temps pour moi. Si cela ne fonctionne pas, supprimez également QTAgent32.exe, puis supprimez les dossiers/bin et/obj du projet en question.
C'est la partie la plus irritante de ma journée de travail. :)
Parfois, il ne peut pas effacer le dossier DEBUG. Ce que j'ai fait et travaillé a été de renommer le fichier qui ne pouvait pas être supprimé. Donc, effacez tout le dossier et le fichier qui ne peut pas être supprimé, renommez-le, par exemple, "_old".
Je n'avais pas réalisé que mon débogueur était toujours connecté et que je tentais de créer la même instance Visual Studio. Une fois que j'ai arrêté le débogueur que j'ai pu construire.
Dans mon cas, c’était le coureur de tests unitaires Resharper (plus les tests NUnit, jamais eu un tel problème avec MsTests). Après avoir tué le processus, a été en mesure de reconstruire le processus, sans redémarrer le système d'exploitation ou VS2013
Dans mon cas, c'était un problème de permission. Je devais exécuter Visual Studio en tant qu'administrateur.
La réponse de Gérard était correcte.
Lorsque clean + build n'a pas résolu ce problème pour moi, j'ai eu du succès en procédant comme suit:
Closing Visual Studio
Deleting the bin and obj folders, and
Reopening Visual Studio.
Mais je devais faire un travail supplémentaire dans la console:
> Add-Migration Initial
> Update-Database
Ensuite, j'ai commencé à déboguer et cela a fonctionné.
J'ai rencontré ce problème dans VS 2015. La raison de mon environnement était l'utilisation du paramètre de projet StyleCop pour StyleCopAdditionalAddinPaths Include = "..." pour spécifier un chemin supplémentaire StyleCop Addin. La solution de contournement que j'ai utilisée consistait à supprimer ce paramètre de projet du fichier .csproj et à copier plutôt le StyleCop AddIn manuellement où le fichier StyleCop.CSharp.Rules.dll était présent. Ce n’est pas une solution élégante, mais j’ai trouvé que la solution ne bloquait jamais les dll après cela.
Dans mon cas (Windows 10, Visual Studio 2015):
Gestionnaire des tâches -> Utilisateurs -> EndTask => vshost.exe
(il redémarre immédiatement et vous pouvez reconstruire)
Le moyen le plus rapide est de changer le type de configuration de construction et de revenir à la configuration précédente.
J'ai rencontré les messages d'erreur lors de la tentative de génération du projet WinForms (XAF) principal. Je n'ai pu exécuter l'application qu'une seule fois, puis arrêter le VS2015 IDE et le redémarrer avant qu'une reconstruction puisse être effectuée. Après quelques fouilles dans les pages de propriétés du projet - dans la page de propriétés "débogage", une case à cocher a été activée - Activez le processus d'hébergement Visual Studio. J'ai décoché et redémarré l'EDI, l'application est en cours de construction sans - impossible de copier les messages {projet} .exe.
J'ai eu le même problème et j'ai essayé de nombreuses façons mentionnées ici, mais aucune d'entre elles ne fonctionnait pour moi, la seule solution qui fonctionnait pour moi:
Suppression de la propriété READ ONLY du dossier DEBUG de ma solution et
Ajout de ceci aux événements de construction: s'il existe "$ (TargetPath) .locked" de "$" (TargetPath) .locked "s'il n'existe pas" $ (TargetPath) .locked "s'il existe" $ (TargetPath) "de déplacer" $ (TargetPath) "" $ (TargetPath) .locked "
Je reçois ce message chaque fois que je déploie si je modifie une page Xaml sur WP8 à l’aide de VS2012.
Je dois soit ne pas ouvrir une page Xaml ou utiliser le processus Explorer pour tuer le processus XDesProc.exe.
Si vous obtenez cette erreur, je vous recommande d'utiliser Process Explorer pour voir ce qui se passe (même s'il s'agit d'un problème différent). Il suffit de trouver le processus "WeinGartner.WeinCad.exe" et il devrait afficher le processus et gérer l'accès au fichier (du moins lorsque la suppression du fichier vhost ne résout pas le problème).
Utilisation de DNN. J'ai résolu le problème en modifiant le fichier MSBuild.Community.Tasks.Targets et en modifiant le chemin de la corbeille:
<MSBuildDnnBinPath Condition="'$(MSBuildDnnBinPath)' == ''">$(MSBuildProjectDirectory)\bin</MSBuildDnnBinPath>
Cela m'est arrivé lors de l'utilisation du plugin IL Support .
Lorsque vous ne disposez d'aucun fichier IL dans votre projet (parce que vous avez supprimé le dernier, par exemple), la génération échoue comme décrit dans la question.
Supprimer le support de IL a résolu le problème
Dans mon cas, le problème était le débogueur distant Visual Studio 2105. Lorsque j'ai tué cette tâche dans le Gestionnaire des tâches, j'ai réussi à reconstruire mon application dans Visual Studio.
J'étais en train de devenir fou d'essayer de comprendre pourquoi le processus System tenait le dossier ouvert sur lequel je travaillais pendant encore une minute après son arrêt et que j'obtenais la même erreur que l'OP.
La raison en était que les développeurs précédents n’ont pas encapsulé les objets IDisposable dans using(){}. Une fois que les objets IDisposable se sont correctement détruits, l'erreur ne s'est plus produite et j'ai été capable de reconstruire immédiatement.
Supprimez tous les fichiers .cache sous vos dossiers Debug ou Release dans le dossier Bin.
Je rencontre régulièrement ce problème également dans Visual Studio 2010. Fermer Visual Studio, supprimer les répertoires bin et obj et le relancer permettra de résoudre le problème pour une construction. Puis le problème revient. J'ai essayé toutes les autres réponses sur ce fil et aucune n'a fonctionné pour moi. Pour moi, la seule solution permanente consiste à accéder aux paramètres du projet et à désactiver "Activer le processus d'hébergement Visual Studio", à créer, à le réactiver, et à reconstruire à nouveau.
J'ai réussi à contourner le problème en exécutant Visual Studio en tant qu'administrateur.
Je suis tombé dessus aussi. Il s’est avéré que j’avais testé avec un service que j’avais construit moi-même et qui n’exécutait plus le répertoire ..\bin\release de l’un des projets de ma solution. Le service est en cours d’exécution, mais j’oublie d’arrêter/de le désinstaller avant de revenir aux tests. En conséquence, elle conservait l'une des dll que je fais référence et qui devait être déplacée (automatiquement en tant que dépendance) d'un sous-dossier bin/release d'un projet à un autre. L'arrêt du service a résolu le problème.
J'ai passé quelques heures à essayer de résoudre ce problème, puis j'ai découvert que je travaillais sur un service. N'oubliez pas d'arrêter tout service dans le cadre de votre solution!
Réinitialisez IIS, arrêtez les services qui utilisent votre DLL (peut-être une application console ou une application hébergée de services Windows ou IIS), puis essayez.
Cela a fonctionné pour moi.
Ajoutez ceci au pré-construit:
(if exist "$(TargetDir)*old.exe" del "$(TargetDir)*old.exe") & (if exist "$(TargetDir)*.exe" ren "$(TargetDir)*.exe" *.old.exe)
Je me rends bien compte que cela ne fait qu’ajouter au nombre déjà considérable de réponses à cette question, mais j’ai pensé qu’il méritait de mentionner que, même si elle n’était pas parfaite, une combinaison des réponses données par: @Stefano, @MichaelRibbons et @IvanFerrerVilla a fourni un élément décent. de succès, alors qu’aucun d’eux seul n’a eu beaucoup de succès.
Recherchez dans le gestionnaire de tâches tout processus exécutant le fichier .exe.
Un autre plaisir, mais c'est facile et cela fonctionne pour moi dans VS 2013. Cliquez sur le projet. Dans le panneau des propriétés doit être une entrée nommée Fichier du projet avec une valeur
(nom de votre projet) .vbproj
Modifiez le nom du projet - en ajoutant par exemple un -01 à la fin. Le fichier .Zip d'origine qui était verrouillé existe toujours, mais n'est plus référencé ... pour que votre travail puisse continuer. Lors du prochain redémarrage de l'ordinateur, ce verrou disparaîtra et vous pourrez supprimer le fichier erroné.
J'ai trouvé une solution complète!
La plupart des réponses vous disent de tuer le processus, cependant avec le processus pirate, je ne pourrait pas en trouver.
J'ai trouvé une solution relativement simple.
- Sélectionnez votre formulaire principal dans le Concepteur de formulaires.
- Cliquez sur l'onglet Événements dans le menu Propriétés.
- Double-cliquez sur l'événement FormClosing. Ceci génère automatiquement le système d’événement et la fonction:
private void [your form name here]_FormClosing(object sender, FormClosingEventArgs e) </ code>
- Dans cette fonction, ajoutez
Application.Exit
Comme suit:
private void Form1_FormClosing(object sender, FormClosingEventArgs e)
{
Application.Exit();
}
</ code>image utile
J'espère que ça aide! Ce problème était vraiment nul!
Fix 2
Activez un service appelé "Expérience d’application".
Dans mon cas, les fichiers que nous ne pouvions pas copier étaient ceux du projet .Task. Le problème était donc que quelques tâches planifiées étaient exécutées localement. Une fois que je les ai arrêtés et désactivés, le problème de copie a disparu.