Nombreuses instances de VBCSCompiler.exe
Je viens de télécharger et d'installer Visual Studio Professional 2015 (14.0.23107.0). La première fois que j'ai ouvert notre solution (28 projets) et procédé à une solution Build -> Rebuild, ma machine de développement a connu une analyse absolue. Le processeur était au maximum à 100% et la construction n’était jamais terminée - même après> 10 minutes.
J'ai ouvert le gestionnaire de tâches Windows et constaté:> 10 tâches VBCSCompiler.exe en cours d'exécution. Lorsqu'elles sont combinées, ces tâches envoient au processeur> 90%.
Avez-vous une idée du nombre de tâches en cours? Un moyen d'empêcher que cela se produise?
C’est la chose la plus proche que je puisse trouver pour une autre personne confrontée au même problème: https://github.com/dotnet/roslyn/issues/279
Mise à jour (8/7)
-Hans Passant, bonne pensée. Mon responsable m'a fourni cette version (14.0.23107.0). Est-ce la version correcte pour la "version officielle" ?? Je n'ai sciemment installé aucune des versions par version de Visual Studio 2015. Je ne pense pas que des bits bêta traînent.
-Kyle Trauberman, je ne connais pas très bien les variables d'environnement dans le contexte de Visual Studio; cependant, j'ai naïvement couru set DisableRosyln=true dans une fenêtre d'invite de commandes VS (et MSBuild). Cela n'a semblé avoir aucun impact. VBCSCompiler.exe a montré une sauvegarde, même après le redémarrage de VS2015.
J'ai réparé mon installation VS2015 et effectué un redémarrage. Cela n'a pas aidé.
Mise à jour de la partie 2 (8/7) -Hans Passant, rédaction très impressionnante !! Bien que le problème ne se soit pas posé cette fois-ci, j'ai jeté un coup d'œil à ce que vous avez décrit:
En ce qui concerne les modules chargés avec VBCSCompiler.exe, voici ce que j'ai:
Il est intéressant de noter que nos assemblys principaux .NET sont à différentes versions. Vous êtes à 4.06.79 alors que je suis à 4.06.81.
Mes "dll côté client" (situées dans C:\Program Files (x86)\MSBuild\14.0\Bin\Microsoft.Build.Tasks.CodeAnalysis.dll) ont la même version et le même horodatage que le vôtre: 
Curieusement, quand je regarde le code dans ILSpy, je vois quelque chose de légèrement différent - l'optimisation peut-être?
private static NamedPipeClientStream TryAllProcesses(string pipeName, int timeoutMs, CancellationToken cancellationToken, out string newPipeName)
{
string str = pipeName;
int num = 1;
while (File.Exists(string.Format("\\\\.\\pipe\\{0}", pipeName)))
{
NamedPipeClientStream result;
if ((result = BuildClient.TryConnectToProcess(pipeName, timeoutMs, cancellationToken)) != null)
{
newPipeName = pipeName;
return result;
}
pipeName = str + "." + num.ToString(CultureInfo.InvariantCulture);
num++;
}
newPipeName = pipeName;
return null;
}
** Laissez-moi vous revenir avec l'argument spécifique pipname transmis aux instances de VBCSCompiler.exe. Je vais devoir attendre que cela se reproduise.
Hmm, il n'y a pas de scénario de reproche évident et personne d'autre ne s'en plaint. Votre solution n'est pas inhabituelle du tout. Associer le processeur à 100% et faire avaler le processus de VBCSCompiler à environ 1,5 Go n’est pas très dur pour un projet volumineux, mais c’est parfaitement net quand je regarde le mien.
Premier scénario d'échec possible avec des bits bêta désinstallés, un problème très courant. Utilisez le débogueur pour voir. Utilisez Debug> Attacher au processus et sélectionnez l’une des instances en cours d’exécution. Ensuite, déboguez> Tout casser et mettez au point> Affichage> Modules. Faites attention aux numéros de version et aux horodatages, ils devraient ressembler à ceci:
Notez que intentionnellement caché certaines colonnes pour le garder lisible. Les horodatages sont des fuseaux horaires CST.
C'est le côté serveur. Le côté client contenant le bogue découvert est situé dans C:\Program Files (x86)\MSBuild\14.0\Bin\Microsoft.Build.Tasks.CodeAnalysis.dll. Regardez ses propriétés, le mien est de 85 192 octets et créé le dimanche 21 juin 2015 à 19h06:54, Numéro de version du fichier 1.0.0.50618. Vous pouvez consulter le fichier avec un décompilateur tel que Reflector ou ILSpy, accédez à BuildClient.TryAllProcesses (). La ligne pertinente avec le correctif est:
for (int i = 1; File.Exists(string.Format(@"\\.\pipe\{0}", pipeName)); i++)
La version buggy manquait \\.\pipe\.
Notez à quel point la vérification d'erreur est très inadéquate dans l'extrait ci-dessus. File.Exists () renvoie false pour plusieurs raisons. Aussi la raison fondamentale pour laquelle le bogue n'a pas été découvert plus tôt. Cela permet plusieurs modes de défaillance possibles, le type activé si votre ordinateur est infecté par le programme malveillant le plus répandu que les programmeurs installent volontairement. Le code serveur et le code client se connectent via un canal nommé portant un nom spécial. Quelque chose que vous pouvez voir dans le Gestionnaire des tâches, onglet Processus. Utilisez Affichage> Sélectionner les colonnes (Win8 et supérieur: cliquez avec le bouton droit de la souris sur l'en-tête d'une colonne) et cochez l'option "Ligne de commande": 
Noter la -pipename argument. Si l'appel File.Exists () renvoie false , MSBuild redémarre VBCSCompiler.exe. Si vous voyez toutes ces instances s'exécuter avec le même argument -pipename, des logiciels s'exécutant sur votre ordinateur interfèrent avec l'utilisation normale du canal nommé. La première chose à considérer est donc de rechercher une solution anti-malware moins agressive. Vous pouvez écrire un petit programme de test utilisant l’espace de noms System.IO.Pipes pour obtenir un meilleur message d’exception.
Avez-vous une idée du nombre de tâches en cours?
Roslyn utilise un processus de compilateur partagé qui garde votre code compilé en mémoire pour une utilisation ultérieure dans les compilations. Donc, la deuxième compilation sera plus rapide, mais comme vous l'avez vu, il y a une surcharge de mémoire.
Un moyen d'empêcher que cela se produise?
Oui. À partir de ici , il existe une propriété de la tâche de compilation dans msbuild qui désactive le compilateur partagé. Elle est définie sur true par par défaut .
Donc, dans chaque projet, vous devrez ajouter cette propriété au fichier de projet. Ou, dans Visual Studio 2015, il existe maintenant des projets partagés, dans lesquels vous pouvez ajouter cette propriété au projet partagé, puis inclure ce projet partagé dans tous les autres projets nécessitant ce paramètre.
<PropertyGroup>
<UseSharedCompilation>false</UseSharedCompilation>
</PropertyGroup>
Au 22 novembre 2015, ce problème me touchait toujours dans l'édition communautaire de Visual Studio 2015. Mon ordinateur portable commençait à faire office de chauffage d'appoint avec toutes les instances de VBCSCompiler fonctionnant à plein régime.
Le seul correctif qui a fonctionné pour moi a été de localiser le fichier VBCSCompiler.exe dans le répertoire/bin/roslyn de l'application Web et de modifier les autorisations de sécurité . .
Vous devez refuser l'autorisation de lecture et d'exécution pour l'AppPool sous lequel votre application Web s'exécute.
Selon Slaks, vous pouvez désactiver roslyn (ce qui semble être le cas de VBCSCompiler.exe) en définissant la variable d'environnement DisableRoslyn sur true.
Voir http://blog.slaks.net/2014-05-21/exploring-rosslyn-part-2-inside-end-user-preview/ pour plus d'informations.
Remarque, le lien ci-dessus est pour l'aperçu, mais je ne peux pas imaginer qu'il aurait beaucoup changé entre hier et aujourd'hui.
Vous pouvez également modifier l'option "Keep Alive" pour VBCSCompiler, pour la fermer juste après l'exécution ... Vous devez modifier le fichier "VBCSCompiler.exe.config" ("C:\Program Files (x86)\MSBuild\14.0\Bin\VBCSCompiler.exe.config ") et définissez la valeur requise en secondes (par défaut 600).
J'ai constaté que le remplacement de l'identité par 'NetworkService' dans les paramètres avancés du pool d'applications résolut le problème pour moi.
Nous avons également rencontré ce problème avec Visual Studio Enterprise 2015, mise à jour 1. Le problème a été résolu en effectuant une mise à niveau vers Update 2.