CruiseControl.NET Préprocesseur 'include' Anomalie

Question

Voici une description étrange concernant une combinaison des fonctionnalités 'define' et 'include' exposées par le préprocesseur CC.NET. Nous exécutons CCNet 1.4.4.83 et notre fichier ccnet.config est structuré et divisé pour utiliser au mieux les blocs d'éléments communs stockés dans les sous-fichiers inclus dans le fichier de configuration principal; nous avons également divisé les définitions du projet de base dans leurs propres fichiers à inclure aussi, laissant ccnet.config comme essentiellement une série de comprend donc:

<cruisecontrol xmlns:cb="urn:ccnet.config.builder"> 
    <!-- Configuration root folder - defined so we can use it as a symbol instead of using slightly confusing relative paths --> 
    <cb:define ccConfigRootFolder="C:\CruiseControl.NET\Config"/> 

<!-- Globals - standard or shared build elements common to all projects --> 
<cb:include href="$(ccConfigRootFolder)\Globals\globals.xml" xmlns:cb="urn:ccnet.config.builder"/> 

<!-- CruiseControl.NET Configuration - refresh configuration if changed --> 
    <cb:include href="$(ccConfigRootFolder)\CCNet Configuration\ccnet_configuration.xml" xmlns:cb="urn:ccnet.config.builder"/> 

<!-- Project #1 --> 
    <cb:include href="$(ccConfigRootFolder)\Project1\project1.xml" xmlns:cb="urn:ccnet.config.builder"/> 

<!-- Project #2 --> 
    <cb:include href="$(ccConfigRootFolder)\Project2\project2.xml" xmlns:cb="urn:ccnet.config.builder"/> 
</cruisecontrol> 

Cela fonctionne un régal - le préprocesseur comprend correctement et analyse les <define> éléments globals.xml (et analyse de manière récursive d'autres fichiers inclus à partir de globals.xml) et les projets inclus par la suite (qui contiennent des références à ces éléments définis) sont analysés correctement.

Pour affiner davantage ccnet.config pour tenter de réduire les risques d'erreurs de rupture du processus de construction, nous avons modifié pour ressembler à ceci:

<cruisecontrol xmlns:cb="urn:ccnet.config.builder"> 
    <!-- Configuration root folder --> 
    <cb:define ccConfigRootFolder="C:\CruiseControl.NET\Config"/> 

    <!-- Project 'include' element definition --> 
    <cb:define name="ProjectInclude"> 
     <cb:include href="$(ccConfigRootFolder)$(ccIncludePath)" xmlns:cb="urn:ccnet.config.builder"/> 
    </cb:define> 

    <!-- Include common gobal elements --> 
    <cb:ProjectInclude ccIncludePath="\Globals\globals.xml"/> 

    <!-- Project #1 --> 
    <cb:ProjectInclude ccIncludePath="\Project1\project1.xml"/> 

    <!-- Project #2 --> 
    <cb:ProjectInclude ccIncludePath="\Project2\project2.xml"/> 
</cruisecontrol> 

Comme vous pouvez le voir, nous avons intégré la commune, répétée, partie de la définition 'include' dans son propre bloc défini, puis utilisez-le pour effectuer chaque inclusion en utilisant le chemin en tant que paramètre - l'idée étant que les futurs modificateurs du fichier n'auront pas la possibilité d'oublier accidentellement quelque chose sur leur nouveau les lignes de projet (telles que le pré-processeur URN); Tant que leur fichier xml existe et qu'ils ont le bon chemin, le reste est pris en charge dans la définition d'inclusion commune.

Le seul problème est que cela ne fonctionne pas - pour une raison quelconque, il semble que le fichier globals.xml n'est pas analysé correctement (ou peut-être même inclus) parce que les projets inclus après se plaindre de ne pas avoir d'éléments définis; c'est-à-dire que les références aux éléments définis dans le fichier globals ne semblent pas avoir été «enregistrées», car les projets ne les reconnaissent pas.

Nous avons essayé de retirer les inclusions imbriquées de globals.xml et de les inclure directement au niveau supérieur, en vain. En commentant la première référence d'élément problématique dans le projet, Validator se contente de se plaindre de la suivante, avec le message "Le pré-traitement a échoué lors du chargement du code XML: référence au symbole inconnu XXXXX". Si nous incorporons le corps de globals.xml dans ccnet.config, cependant, cela fonctionne. Aussi bizarre que cela puisse paraître, c'est comme si le préprocesseur échouait totalement à analyser globals.xml, mais qu'il masquait ensuite joyeusement les fichiers du projet, pour ensuite échouer car les références globales ne sont pas définies.

Le validateur échoue silencieusement si tel est le cas, cependant. Et bien sûr, parce qu'il ne peut pas analyser correctement le XML du projet, nous n'obtenons rien non plus dans les onglets "Original" et "Traité". Le service CruiseControl.NET lui-même ne parvient pas à démarrer avec une exception inutile:

Le service ne peut pas être démarré. System.Runtime.Serialization.SerializationException: Type de 'ThoughtWorks.CruiseControl.Core.Config.Preprocessor.EvaluationException' à l'Assemblée « ThoughtWorks.CruiseControl.Core, Version = 1.4.4.83, Culture = neutral, PublicKeyToken = null 'n'est pas marqué comme sérialisable. Trace de la pile du serveur: à System.Runtime.Serialization.Formatters.Binary.WriteObjectInfo.InitSerialize (Object obj , ISurrogateSelector surrogateSelector, StreamingContext contexte, SerObjectInfoInit serObjectInfoInit, convertisseur IFormatterConverter , ObjectWriter objectWriter) à System.Runtime.Serialization.Formatters.Binary.WriteObjectInfo.Serialize (Object obj , ISurrogateSelector surrogateSelector, StreamingContext contexte, serObjectInfoInit serObjectInfoInit, convertisseur IFormatterConverter , ObjectWriter objectWriter) à System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Serialize (graphique objet , H Eader [] inHeaders, __BinaryWriter serWriter, Boolean fcheck) à System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Ser ...

Toute la documentation indique que cela devrait fonctionner, et il n'y a aucune mention de incompatibilité ou incohérence lors de l'utilisation de 'include' dans un 'define'. Donc je suis perplexe, et toute idée ou conseil serait, à ce stade, hautement considéré.

Answer 1

nous travaillons à résoudre ce problème pour la version 1.5 (fin, espérons ce mois-ci) http://jira.public.thoughtworks.org/browse/CCNET-1865

Sincères salutations Ruben Willems

Answer 2

CCNet 1.5 final a été publié, donc cela vous donne la excuse pour le tester :-) Si le problème persiste, vous pouvez également me contacter via les listes ccnet. http://groups.google.com.ag/group/ccnet-user ou http://groups.google.com.ag/group/ccnet-devel