【问题标题】:How do you build a Windows Workflow Project with NAnt 0.90?如何使用 NAnt 0.90 构建 Windows 工作流项目?
【发布时间】:2010-05-21 17:39:51
【问题描述】:

我正在尝试使用 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: 命名空间不直接包含字段或方法等成员

【问题讨论】:

    标签: c# .net-3.5 workflow-foundation nant


    【解决方案1】:

    如果您查看 Visual Studio/MSBuild 如何编译 WF 项目,您会发现它需要更多。

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

    【讨论】:

    • 同意。将编译委托给 MSBuild 是最简单的,而 NAnt 可以做其他所有事情。调用 MSBuild 比直接调用编译器要多。
    • 这当然是我过去的做法。我希望在 0.90 中添加一些考虑因素,使我能够仅使用 NAnt 构建它。
    • 我不想说 NAnt 已经死了,但它在 2006 年或 2007 年对我来说已经死了。
    • 看起来 WFC.exe 是编译 .xoml 文件的命令行工具。我现在将使用 msbuild 来编译这个项目,但我会看看以后是否可以使用 NAnt 和 WFC 来完成。
    【解决方案2】:

    为什么不直接调用编译器,为什么不用MSBuild呢?它处理编译、引用等,因为它在解决方案文件中起作用。所以将使用解决方案和项目中的设置,您不需要像示例中那样写出参数。

    NAnt 不像编译器那样对 MSBuild 有任何直接的功能;但是,NAntContrib 有一个msbuild 任务。这就是我使用的,它使我的构建脚本中的编译过程非常简单。这是我的编译任务的样子:

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

    【讨论】:

    • 我现在实际上是从 CC.Net 调用 msbuild 来构建这个特定的项目,因为似乎没有替代方案。我对 NAnt 的偏好实际上是因为它不使用 .csproj 文件。这允许我创建一个独立于对项目文件所做的任何更改的构建配置。我认为它更加一致,并且由于对项目文件的无意更改而不太容易构建错误。我确信我可以使用 msbuild 完成此任务,此时我对 NAnt 更加熟悉。
    • 嗨,@LockeCJ,我认为没有多少人会选择你对 NAnt 的偏好。应该使用 csproj,因为您的构建需要与开发人员同步。过去,为相同的东西保留 csproj 和 NAnt 脚本对我来说是可怕的。我同意对 csproj 文件进行意外更改,但为什么它们不会出现在您的 NAnt 脚本中?如果你有办法防止对 NAnt 脚本进行更改,我相信 csproj 文件有办法,对吧?
    • 我同意保持 NAnt 构建脚本与项目文件同步需要做一些额外的工作,但我认为这种一致性是值得的。通过将它们分开,我保证不会“意外”对软件的构建方式进行更改。对项目文件的更改所需要的任何更改都可以在包含之前进行识别和评估。我的经验有所不同,因为 NAnt 文件只需要偶尔进行调整,但 .csproj 文件需要更频繁地更正,因为 Visual Studio 会进行特定于机器的更改。
    猜你喜欢
    • 1970-01-01
    • 2010-09-10
    • 2010-11-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2010-11-16
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多