Discussion :

[jenramac]

Bonjour,

Je débute mon apprentissage du C# via le bouquin Essential C# et Visual Studio Express 2013 pour Desktop sous windows 7. Visual Studio indique (Administrateur), je suis le seul utilisateur hobbyste.

Je créée donc mon programme console, la génération et l'exécution se passe bien via ctrl + F5. Je fais une petite modification, je veux recompiler, la régénération échoue car on ne peut écrire le fichier exe car utiliser par un autre processus.

Je lance donc le gestionnaire des tâches et effectivement tourne xxxxx.vshost.exe dans les services que je dois tuer pour refaire une compilation et ceci à chaque modification, j'ai vu que je peux dans les propriétés/Déboguer désactiver le "processus d'hébergement de visual studio" mais apparemment cela me fera perdre certaines fonctions de débogage.

Parfois, le service xxxx.vshost.exe réapparaît immédiatement après avoir été tué et je suis bon à jouer sur la case à cocher, changer de solution ou quitter visual studio.

J'ai déjà fait une recherche sur ce site via vshost.exe mais les solutions proposées ne me correspondent pas.

Merci d'avance.

[DotNetMatt]

CTRL + F5 ça sert à "exécuter sans débogage", ça ne sert pas qu'à compiler...

Pour simplement compiler, sans exécuter, tu peux utiliser CTRL + SHIT + B (ou F6) puis builder la solution.

Si tu veux compiler puis exécuter, tu peux utiliser F5 tout seul, ce qui permet d'utiliser les fonctionnalités de débogage de Visual Studio. Tu ne pourras pas modifier ton code pendant l'exécution. Il faudra fermer l'application, modifier ton code, puis refaire F5 pour tester les modifications.

Enfin, si tu veux continuer à utiliser CTRL + F5, alors n'oublie pas de fermer ton application avant de modifier ton code et de relancer une compilation.

[jenramac]

Bonjour,

Merci pour la réponse, si je suis débutant en C#, j'ai une bonne expérience en Delphi et je ne tente pas de recompiler mon programme pendant qu'il s'exécute encore, je laisse bien le programme console se terminer, ensuite je tente la modification mais le build ne fonctionne pas non plus car il ne peut écraser l'exe toujours verrouiller par svhost.exe.

J'ai remarqué qu'après un certain temps malgré que xxxx.vshost.exe soit toujours présent, le build est possible comme si le fichier est déverrouillé après un certain temps..

J'ai le même problème que ICI

Merci pour l'aide

Edit : correction orthographe et changement de svhost en vshost.


[Edit 2]
Bonjour,

Je viens de passer mon compte en mode standard, visual studio ne fonctionne plus en mode administrateur, le résultat est identique!

J'ai également testé avec la version de VS 2013 PRO en évaluation et de même.

Cela plante également si je désactive "le processus d'hébergement de visual studio".

J'ai remarqué également que MSBuild.exe restait aussi plus longtemps que prévu mais le tuer ne change rien.

Je dois chaque fois attendre une bonne minute pour que le programme soit déverrouillé pour la réécriture.

Je vais chercher un programme qui va me permettre de savoir qui maintien le verrouillage sur ce fichier.


[edit3]

Après analyse avec Process Explorer, il s'agit apparament du thread system (PID 4) qui verrouille le fichier mais aucune autre information !

J'ai désactivé anti-virus, Windows defender, l'indexation automatique, nada!

J'ai également remarqué que si je relance une compilation endéans 67 secondes, que je ferme la solution et la rouvre ou que je quitte/relance Visual studio, le résultat est le même!

Je vais donc en rester là! Une minute entre les compilations, ce n'est pas la mer à boire et ça permet de réfléchir un peu plus!

Quelqu'un a-t-il la même chose?

[jenramac]

Bonjour,

Je viens de tester l'expérience avec csc.exe et notepad++ (visual studio fermé) et là miracle, compilation à la chaîne!

Par contre, si j'exécute le programme entre deux compilations, je suis verrouillé pendant 67 secondes.

Serait-ce cmd.exe utilisé par Visual Studio qui bloque l'écriture de l'exe?

Je viens de lire LockFile function sur MSDN et particulièrement ceci :

If a process terminates with a portion of a file locked or closes a file that has outstanding locks, the locks are unlocked by the operating system. However, the time it takes for the operating system to unlock these locks depends upon available system resources. Therefore, it is recommended that your process explicitly unlock all files it has locked when it terminates. If this is not done, access to these files may be denied if the operating system has not yet unlocked them.

Ceci expliquerait peut-être pourquoi le fichier appartient à SYSTEM pendant la durée du verrouillage mais je suis TRES TRES loin d'être compétent dans ce domaine.

Existe-t-il un programme qui permettrait de déverrouiller le fichier rapidement ? Il faudrait récupérer le handle de fichier, se l'approprier, le déverrouiller et faire en sorte que ce programme se lance en PREBUILD mais est-ce possible, avis aux experts!

[Edit]

Je viens d'utiliser Unlocker qui permet d'effacer le fichier et de gagner du temps, je l'ai donc ajouter au outil externe avec comme Arguments :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$(BinDir)$(TargetName)$(TargetExt) /S /D

Il y a surement moyen de faire une ligne d'argument plus courte mais cela fonctionne pour le moment, si je choisi cible, il prend le répertoire OBJ lieu du BIN.

Et cela fonctionne impeccablement, si je lance unlocker depuis outil, la compilation/exécution se produit immédiatement!

J'y arrive doucement!

[Edit]

Merci d'avance de vos réponses.