2010-05-21 17 views
0

J'essaie de créer un projet Windows Workflow (WF) en utilisant NAnt, mais il ne semble pas être capable de générer les fichiers ".xoml" et ".rules".Comment construire un projet Windows Workflow avec NAnt 0.90?

Voici le code de la tâche que je csc en utilisant:

<csc debug="${build.Debug}" warninglevel="${build.WarningLevel}" target="library" output="${path::combine(build.OutputDir,assembly.Name+'.dll')}" verbose="${build.Verbose}" doc="${path::combine(build.OutputDir,assembly.Name+'.xml')}"> 
    <sources basedir="${assembly.BaseDir}"> 
    <include name="**/*.cs" /> 
    <include name="**/*.xoml" /> 
    <include name="**/*.rules" /> 
    </sources> 
    <resources basedir="${assembly.BaseDir}"> 
    <include name="**/*.xsd" /> 
    <include name="**/*.resx" /> 
    </resources> 
    <references> 
    ... 
    </references> 
</csc> 

Voici la sortie:

21 fichiers à la compilation 'c: \ Output \ MyWorkFlowProject.dll'.

[csc] c: \ Projects \ MyWorkFlowProject \ AProcessFlow.xoml (1,1): erreur CS0116: un espace de nommage ne contient pas directement les membres tels que des champs ou des méthodes

[CSC] c: \ Projects \ MyWorkFlowProject \ BProcessFlow.xoml (1,1): erreur CS0116: un espace de noms ne contient pas directement des membres tels que des champs ou des méthodes

[csc] c: \ Projects \ MyWorkFlowProject \ CProcessFlow.rules (1,1): erreur CS0116: Un espace de noms ne contient pas directement de membres tels que des champs ou des méthodes

[csc] c: \ Projets \ MyWorkFlowProject \ CProcessFlow.xoml (1,1): erreur CS0116: Un espace de nommage ne contient pas directement de membres tels que des champs ou des méthodes

Répondre

2

Si vous regardez comment Visual Studio/MSBuild compile un projet WF, vous verrez qu'il en faut beaucoup plus. Par conséquent, utilisez NAnt pour piloter MSBuild et compiler les fichiers de projet Visual Studio pour vous est de loin la meilleure et la seule option.

+0

D'accord. Il est plus facile de déléguer la compilation à MSBuild, et NAnt peut faire tout le reste. L'appel de MSBuild ne se limite pas à l'appel direct du compilateur. –

+0

C'est certainement comme ça que je l'ai fait par le passé. J'espérais qu'il y aurait quelques considérations ajoutées à 0.90 qui me permettraient de le construire en utilisant seulement NAnt. – LockeCJ

+0

Je ne veux pas dire que NAnt est mort, mais il était déjà mort pour moi en 2006 ou 2007. –

0

Au lieu d'appeler le compilateur directement, pourquoi ne pas utiliser MSBuild? Il gère la compilation, les références, etc. car il fonctionne sur le fichier de solution. Ainsi, les paramètres de la solution et des projets seront utilisés, vous n'avez pas besoin d'écrire les paramètres comme dans votre exemple.

NAnt n'a aucune fonctionnalité directe pour MSBuild comme pour les compilateurs; cependant, NAntContrib a une tâche msbuild. C'est ce que j'utilise, cela rend le processus de compilation très simple dans mon script de construction. Voici à quoi ressemble ma tâche de compilation:

<target name="compile" description="build the application"> 
    <loadtasks assembly="${dir.tools}\nantcontrib\NAnt.Contrib.Tasks.dll" /> 

    <msbuild project="${dir.src}\${file.solution}" verbosity="Minimal" failonerror="true" verbose="false"> 
     <property name="Configuration" value="${project.config}" /> 
    </msbuild> 
</target> 
+0

J'appelle en fait msbuild de CC.Net pour construire ce projet particulier pour l'instant, car il ne semble pas y avoir d'alternative. Ma préférence pour NAnt est en fait parce qu'il n'utilise pas les fichiers .csproj. Cela me permet de créer une configuration de construction indépendante de toute modification apportée aux fichiers du projet. Je pense que c'est un peu plus cohérent, et moins enclin à générer des erreurs en raison de changements involontaires dans les fichiers du projet. Je suis sûr que je pourrais accomplir cela avec msbuild, je suis juste beaucoup plus familier avec NAnt à ce stade. – LockeCJ

+0

Salut, @LockeCJ, je pense que peu de gens choisissent votre préférence pour NAnt. csproj devrait être utilisé car votre build doit être synchronisé avec les développeurs.Garder à la fois csproj et NAnt script pour les mêmes choses est horrible pour moi dans le passé. Je suis d'accord que des changements involontaires viennent aux fichiers de csproj, mais pourquoi ils ne viennent pas à votre script NAnt? Si vous avez un moyen d'empêcher les modifications apportées aux scripts NAnt, je crois qu'il existe un moyen pour les fichiers csproj, non? –

+0

Je suis d'accord qu'il y a un travail supplémentaire à faire pour synchroniser les scripts de construction de NAnt avec les fichiers de projet, mais je pense que la cohérence en vaut la peine. En les gardant séparés, je garantis qu'aucun changement dans la construction du logiciel n'est fait "accidentellement". Toute modification requise par les modifications apportées aux fichiers de projet peut être identifiée et évaluée avant d'être incluse. Mon expérience a été différente, dans la mesure où les fichiers NAnt n'ont besoin que d'ajustements occasionnels, mais les fichiers .csproj doivent être corrigés beaucoup plus souvent en raison des changements spécifiques à Visual Studio. – LockeCJ