Visual Studio reconstruit des projets non modifiés

Donc, comme le titre l’indique, j’ai une solution VS2010 avec environ 50 projets en ce moment. Si je modifie un projet “de haut niveau” auquel rien ne fait référence, VS reconstruit toujours les 50 projets. Je lance Visual Studio 2010 Ultimate sans add-on. J’utilise ILMerge pour consolider tous les projets dans un seul fichier.

Je l’ai vérifié en vérifiant les horodatages des dll de niveau inférieur et en vérifiant qu’ils sont bien reconstruits même si leur code n’a pas été touché.

J’ai lu toutes les réponses et commentaires pour:

Visual Studio 2008 continue à reconstruire

Visual studio continue à tout construire

Ssortingck VS2010 construire problème se produit dans ma solution

Raisons pour lesquelles les projets C # doivent être reconstruits dans Visual Studio

Mais la plupart d’entre eux n’offrent que des suggestions sur les projets de déchargement pour accélérer les temps de construction, mais rien de concret en termes de correction. J’essaie de comprendre pourquoi VS pense que ces projets dépendants doivent être reconstruits lorsqu’ils ne le font pas et le réparer.

J’ai activé ‘Outils> Options> Projets et solutions> Créer et exécuter> Construire uniquement des projets de démarrage et des dépendances à l’exécution, mais sans aucun effet.

De plus, si je reconstruis simplement un projet “de niveau intermédiaire” qui ne comporte que 8 dépendances directes, il construit toujours les 8 projets même si ILMerge n’est pas appelé et qu’aucun des projets dépendants n’a été modifié.

Merci à tous pour tout renseignement que vous pourriez nous fournir.

Ajoutée

Pour tester certaines des suggestions, j’ai créé un nouveau projet WinForms à partir de zéro. J’ai ensuite créé deux nouveaux projets dans cette solution. J’ai copié tout le code et toutes les ressources (pas le fichier de projet) de mes deux projets de «plus bas niveau» dans les deux nouveaux projets (j’ai fait cela en déposant les fichiers et dossiers d’Explorer sur le projet dans Visual Studio).

Le projet le plus bas, appelons-le B , ne fait référence à aucun autre projet. Le projet suivant, A , référencé B uniquement. Donc, une fois que j’ai ajouté les références .NET et les assemblages externes requirejs aux projets, la solution se construirait.

J’ai ensuite eu ma nouvelle référence de projet WinForm A et j’ai effectué une compilation complète. La chaîne de référence est donc:

WinForm -> A -> B

J’ai ensuite modifié WinForm uniquement et réalisé une version standard (F6). Comme auparavant, Visual Studio a reconstruit les trois projets.

Après une élimination systématique des fichiers sources dans le projet B, j’ai constaté que si je supprimais mes Resources.Designer.cs et Resources.resx (et commentais le code qui utilisait l’object .Properties.Resources de ces ressources), une modification de WinForm ne reconstruirait plus la totalité de la solution et ne reconstruirait que WinForm .

L’ajout des Resources.resx et Resources.Designer.cs au projet B (mais en laissant le code référencé commenté pour que rien n’utilise les ressources) réintroduirait le comportement de la génération complète.

Pour voir si mes fichiers de ressources étaient peut-être endommagés, je les ai supprimés à nouveau, puis créé un nouveau fichier (via Propriétés du projet -> Ressources) et ajouté à nouveau la même ressource, qui était un fichier Excel unique. Avec cette configuration, la reconstruction complète se produirait toujours.

J’ai ensuite supprimé la ressource unique, mais j’ai laissé le fichier de ressources dans le projet B. Même sans aucune ressource ajoutée, mais le fichier de ressources encore dans le projet, la reconstruction complète (inutile) se produirait.

Il semble que le simple ajout d’un fichier de ressources à un projet (.NET 3.5) entraîne toujours la reconstruction de ce projet par Visual Studio 2010. Est-ce un bug ou un comportement prévu / prévu?

Merci encore!

Ouvrez Outils – Options, sélectionnez Projets et solutions – Construire et exécuter dans l’arborescence, puis définissez “Verbosité de sortie du projet MSBuild” sur Diagnostic. Cela produira la raison de la construction d’un projet, c.-à-d.

Le projet ‘ReferencedProject’ n’est pas à jour. L’élément de projet ‘c: \ some.xml’ contient l’atsortingbut ‘Copy to Output Directory’ défini sur ‘Copy always’.

Le projet “MyProject” n’est pas à jour. Le fichier d’entrée ‘c: \ ReferencedProject.dll’ est modifié après le fichier de sortie ‘c: \ MyProject.pdb’.

Dans ce cas, le correctif consiste à copier some.xml uniquement s’il est plus récent.

Les événements pré et post-build peuvent également déclencher la génération.

Bien que je ne pense pas que ce soit un correctif, c’est une solution de contournement qui a fonctionné pour ma situation …

Au départ, j’avais environ 5 projets sur 50 qui contenaient une section Resources . Ces projets seraient toujours reconstruits et donc tout ce dont ils dépendaient serait également reconstruit. Un de ces 5 projets était une bibliothèque de niveau “de base” sur laquelle 48 des autres projets faisaient référence. Ainsi, 96% de mon projet serait reconstruit à chaque fois, même s’il n’en avait pas besoin.

Ma solution consistait à utiliser l’dependency injection, les interfaces et un projet “Ressources” dédié. Au lieu que ces 5 projets fassent référence à leur propre object Resources , j’ai créé une interface dans chaque projet qui fournirait les ressources souhaitées. Ensuite, les classes ayant besoin de ces ressources nécessiteraient que cette interface soit transmise lors de leur création dans le constructeur (injection du constructeur).

J’ai ensuite créé un projet “Ressources” distinct qui comportait une section Ressources comme d’habitude. Ce projet ne contenait que les ressources elles-mêmes et une classe pour chaque interface nécessaire pour fournir ces ressources via une interface. Ce projet ferait référence à tous les autres projets ayant une dépendance de ressources et implémenterait l’interface requirejse par le projet.

Enfin, dans mon projet “Top Level” auquel rien ne faisait référence (et où l’exe a été construit et la vie de la racine de la composition), j’ai référencé le projet “Resources”, connecté la DI et nous sums partis.

Cela signifie que seuls deux projets (les “Ressources” et le “Niveau supérieur”) seront reconstruits à chaque fois, et si je fais une construction partielle (Shift-F6), ils ne seront pas du tout reconstruits.

Encore une fois, pas un travail formidable, mais avec 48 projets en cours de construction chaque fois qu’un build prend environ 3 minutes, je perdais 30 à 90 minutes par jour avec des reconstructions inutiles. Cela a pris du temps à refaire, mais je pense que c’était un bon investissement.

Voici un schéma simplifié. Notez que les dépendances de Main.exe vers Proj1 et Proj2 ne sont pas affichées afin de réduire l’encombrement.

Diagramme de solution

Avec cette conception, je peux faire une construction de Proj1 ou Proj2 sans déclencher une reconstruction complète, car ils ne comportent aucune dépendance sur une section Resources . Seul Main connaît la mise en œuvre des Resources .

Cela se produit lorsqu’un projet a un fichier qui n’existe pas vraiment.
Le projet ne peut pas déterminer si le fichier a été modifié (car il n’y en a pas) pour qu’il se reconstruise.

Il suffit de regarder tous les fichiers du projet et de rechercher celui qui n’a pas de flèche extensible à proximité.

J’ai eu le même problème dans VS 2015.

Ce qui a fait l’affaire pour moi c’est:

  1. Un projet se référait à lui-même dans une autre corbeille de projet (magique, oui). Ce genre de choses pourrait être trouvé lors du passage à la sortie de construction de diagnostic (dans les options de construction), puis en essayant de construire des projets un par un à partir de la hiérarchie supérieure des projets. les références.
  2. J’ai changé tous les fichiers “copy always” dans tous les projets pour “copier si plus récent”. Fondamentalement, dans tous les fichiers .csproj, remplacez Always par PreserveNewest
  3. Ensuite, j’ai désactivé le tunneling NTFS comme décrit dans cet article avec ce script powershell:

New-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "MaximumTunnelEnsortinges" -Value 0 -PropertyType "DWord"

Après cela, j’ai eu besoin de reconstruire et cela semble fonctionner pour le moment.

Dans mon cas, le coupable était le paramètre “Copier local” d’un dll référencé défini sur true et “Copy to Output Directory” définissant un ensemble de fichiers sur Copy always.

J’ai finalement trouvé un autre coupable que j’avais du mal à trouver en augmentant la verbosité du journal de compilation.

Dans certains cas, MSBuild recherche vc120.pdb dans le dossier de sortie et si ce fichier n’existe pas, il reconstruira le projet entier. Cela se produit même si vous avez désactivé la génération du symbole de débogage .

La solution à ce problème consiste à activer les symboles de débogage et à laisser ce fichier généré, puis à désactiver le paramètre sans supprimer le fichier PDB.

Voici une réponse de VS2010 toujours reconstruire la solution?

Ce problème est résolu en modifiant les fichiers du projet, en nettoyant la solution, en supprimant tous les dossiers de la corbeille à la main, en redémarrant Visual Studio et en reconstruisant tout.

D’après vos observations, il semble que vous ayez des projets exprimant des dépendances par rapport à d’autres projets d’une manière qui n’est pas évidente. Il est possible que des dépendances orphelines restnt dans des fichiers de projet sans être visibles dans l’interface utilisateur. Avez-vous consulté un fichier de projet défectueux après l’avoir ouvert dans un éditeur de texte? Solution vérifiée construire des dépendances?

Si vous ne parvenez pas à identifier quelque chose, essayez de recréer un de vos projets à partir de zéro pour voir si le nouveau projet présente le même problème. Si le projet propre se construit correctement, vous saurez que vous avez des dépendances indésirables exprimées quelque part. Pour autant que je sache, ces fichiers doivent figurer dans le ou les fichiers du projet ou dans le fichier de solution, à moins que vous ne disposiez de fichiers makefiles ou d’autres étapes de construction inhabituelles.

J’ai eu les mêmes problèmes avec vous. J’ai trouvé que cela venait de certains fichiers supprimés. Lorsque j’ai retiré les fichiers de mon projet, les problèmes ont disparu. Cordialement.

Pour cette catégorie de problèmes de construction, la définition de la sortie de MSBuild en “diagnostic” est en effet une première étape nécessaire. La plupart du temps, la raison indiquée pour les reconstructions serait suffisante pour agir, MAIS occasionnellement, MSBuild affirmerait à tort que certains fichiers sont modifiés et doivent être copiés.

Si tel est le cas, vous devez soit désactiver le tunneling NTFS, soit dupliquer votre dossier de sortie vers un nouvel emplacement. Ici c’est en plus de mots.

Un autre problème qui survient fréquemment est le moment où un élément de votre solution comporte un tampon modifié. Cela peut se produire si vous réglez votre horloge vers l’avant, puis réglez votre horloge à l’heure correcte. Je l’ai eu lors de l’installation de Linux.

Dans ce cas, vous pouvez toucher récursivement tous les fichiers en utilisant git bash (oui, sous Windows):

 find . -exec touch {} \; 

L’équipe MSBuild recueille de la documentation sur l’investigation des problèmes d’incrémentalité de construction ici: https://github.com/Microsoft/MSBuild/wiki/Rebuilding%20when%20nothing%20changed

J’ai eu le problème des projets de reconstruction de Visual Studio lors de la mise à niveau de Visual Studio 2015 vers 2017 et j’ajoute cette réponse pour ceux qui pourraient rencontrer des problèmes similaires, car cela ne semble pas être documenté.

Dans mon cas, le problème était que tous les projets de la solution avaient le même chemin de sortie intermédiaire (obj). Le fichier GeneratedInternalTypeHelper.cs est généré par tous les projets contenant XAML. Jusqu’à Visual Studio 2015, le processus de génération n’a apparemment pas vérifié la date du fichier de ce fichier et aucun problème n’est survenu. Avec VS2017, la date de fichier de ce fichier est vérifiée et comme un projet ultérieur dans le processus de génération le remplacera (avec le même contenu), le projet précédent sera reconstruit, ce qui déclenchera la dernière version, à l’infini.

La solution dans ce cas est de s’assurer que tous les projets ont des répertoires de sortie intermédiaires différents, ce qui fera disparaître le problème.