C# 如何使用NAnt 0.90构建Windows工作流项目？

我正在尝试使用NAnt构建一个Windows工作流（WF）项目，但它没有；似乎无法构建“.xoml”和“.rules”文件

以下是我正在使用的csc任务的代码：

<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>

...

以下是输出：

正在将21个文件编译为“c:\Output\MyWorkFlowProject.dll”

[csc]c:\Projects\MyWorkFlowProject\AProcessFlow.xoml（1,1）：错误CS0116:命名空间不直接包含字段或方法等成员

[csc]c:\Projects\MyWorkFlowProject\BProcessFlow.xoml（1,1）：错误CS0116:命名空间不直接包含字段或方法等成员

[csc]c:\Projects\MyWorkFlowProject\CProcessFlow.rules（1,1）：错误CS0116:命名空间不直接包含字段或方法等成员

[csc]c:\Projects\MyWorkFlowProject\CProcessFlow.xoml（1,1）：错误CS0116:命名空间不直接包含字段或方法等成员

---

如果您查看VisualStudio/MSBuild如何编译WF项目，您将看到它需要更多

---

因此，使用NAnt驱动MSBuild并为您编译Visual Studio项目文件是目前为止最好的也是唯一的选择。

与其直接调用编译器，为什么不使用MSBuild？它处理编译、引用等，因为它是在解决方案文件之外工作的。因此将使用解决方案和项目中的设置，您不需要像示例中那样写出参数

NAnt对于MSBuild没有任何与编译器类似的直接功能；然而，NAntContrib有一项任务。这就是我使用的，它使编译过程在我的构建脚本中非常简单。这就是我的编译任务的样子：

<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>

同意。将编译委托给MSBuild是最容易的，NAnt可以完成其他所有工作。调用MSBuild不仅仅是直接调用编译器，我过去确实是这样做的。我希望在0.90中添加一些考虑因素，使我能够仅使用NAnt构建它。我不想说NAnt已经死了，但它在2006年或2007年对我来说已经死了。看起来WFC.exe是编译.xoml文件的命令行工具。目前我将使用msbuild编译此项目，但稍后我将查看是否有可能使用NAnt和WFC完成此操作。实际上，我正在从CC.Net调用msbuild来生成此特定项目，因为似乎没有替代方案。我对NAnt的偏好实际上是因为它不使用.csproj文件。这允许我创建独立于对项目文件所做的任何更改的生成配置。我认为它更加一致，并且不太容易由于对项目文件的无意更改而产生构建错误。我相信我可以用msbuild实现这一点，我现在对NAnt更为熟悉。嗨，@LockeCJ，我想没有多少人会选择你喜欢的NAnt。应该使用csproj，因为您的构建需要与开发人员同步。在过去，将csproj和NAnt脚本保留在同一个东西上对我来说是可怕的。我同意无意中的更改会出现在csproj文件中，但为什么它们不会出现在NAnt脚本中呢？如果你有办法阻止对NAnt脚本的更改，我相信csproj文件也有办法，对吧？我同意在保持NAnt构建脚本与项目文件同步方面还需要做一些额外的工作，但我认为保持一致性是值得的。通过将它们分开，我保证不会“意外”更改软件的构建方式。项目文件变更所需的任何变更可在纳入之前进行识别和评估。我的经验有所不同，NAnt文件只需要偶尔调整，但是.csproj文件需要更频繁地更正，因为VisualStudio进行了特定于机器的更改。