MSBUILD Erreur MSB4025 dans l'étape de génération de TeamCity pour Visual Studio
Lorsque j'exécute ma version TeamCity avec la seule étape de génération du type runner Visual Studio (sln), le message d'erreur suivant s'affiche:
C:\TeamCity\buildAgent\work\4978ec6ee0ade5b4\Test\Code\Test.sln(2, 1): error MSB4025: The project file could not be loaded. Data at the root level is invalid. Line 2, position 1.
C'est sur un serveur CI dédié exécutant TeamCity Professional 8.1.1 (build 29939). Il existe plusieurs autres versions exécutées avec succès sur ce serveur.
Ce qui est étrange, c’est que la même version fonctionne correctement sur TeamCity sur ma machine de développement. J'ai suivi une réponse à une question similaire et j'ai copié les dossiers spécifiés, mais cela n'a pas aidé.
Je suis sûr que le fichier projet/solution n’est pas invalide car, en plus de la construction exécutée sur ma boîte de dev, j’ai ouvert la solution dans Visual Studio et l’ai construite sans problèmes.
Aucune suggestion?
Je viens de réparer ça.
Recherchez dans le fichier Test.sln les balises Project ou EndProject non fermées. Pour nous, le EndProject était manquant et il a éclaté sur teamcity, mais aucun problème dans Visual Studio.
Il semble que le message d'erreur TeamCity se produira pour un nombre quelconque de causes premières. Dans mon cas, le problème est dû au fait qu’une ligne de la section GlobalSection (NestedProjects) faisait référence à un projet Guid ne faisant référence à aucun projet défini dans le fichier Solution.
Comme dans le post précédent, je n'ai rencontré aucun problème de construction dans Visual Studio. Je n'ai reçu qu'un message d'erreur plus utile qui m'a permis de découvrir quel était le véritable problème lorsque j'ai créé avec msbuild.
Voir https://therightjoin.wordpress.com/2014/07/04/msb4025-the-project-file-could-not-be-loaded-data-at-the-root-level-is-invalid-error -when-building-ssdt-project-in-teamcity pour un autre exemple, et l'utilisation de msbuild a permis d'identifier le véritable problème.
Dans notre cas, il s'agissait d'une référence de projet en double dans le fichier de solution (provoquée par des validations quasi simultanées et une fusion automatique).
Dans un autre cas
Nous avions des lignes vierges - assurez-vous donc que toutes les lignes vides sont supprimées!
J'espère que cela aide les autres aussi!
J'ai la même erreur avec Jenkins. Il s'avère que le dossier racine Jenkins était défini sur C:\Program Files (x86)\et qu'il n'avait pas d'accès en écriture aux répertoires bin et obj.
Erreur: Erreur MSB4025: le fichier de projet n'a pas pu être chargé. Les données au niveau racine ne sont pas valides.
J'ai lancé cmd en tant qu'administrateur et j'ai lancé ceci: "C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" "C:\Program Files (x86)\Jenkins\workspace\BuildBI_1\Reports\Test\ReportsTests.sln "/ t: Générer/p: RunOctoPack = true
Et cela m'a donné des indices sur le fait de ne pas pouvoir écrire à bin et à obj.
Dans mon cas, après la fusion, dans le fichier .sln, c’était une incompatibilité de lignes sous
GlobalSection(NestedProjects) = preSolution
{6B971E15-6B61-4AA8-9B93-9639C23269C3} = {9A14E7EF-3FA1-4B9A-B413-C550B3E5AC62}
{54D14F01-D576-4DE6-9404-D21AD0DC4916} = {9A14E7EF-3FA1-4B9A-B413-C550B3E5AC62}
... (was some extra entry here )
...
EndGlobalSection
section. En termes clairs, des lignes supplémentaires ont été ajoutées après la fusion. Donc, si vous avez fusionné, comparez deux fichiers de solution manuellement. Vous pouvez commencer avec le nombre total de lignes dans les deux fichiers.
Dans notre cas, le problème était de spécifier une ToolsVersion qui n'était pas installée sur cette machine. (14 dont VS2015 a mais VS2017 n'a pas par défaut)
Cela a fonctionné pour moi - Vous pouvez installer Construire des outils pour Visual Studio 2017 , assurez-vous de sélectionner les outils C++, le SDK Windows 10, MSBuild et votre ensemble.