views:

168

answers:

2

I'm trying to build a Windows Workflow (WF) project using NAnt, but it doesn;t seem to be able to build the ".xoml" and ".rules" files.

Here is the code of the csc task that I'm using:

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

Here's the output:

Compiling 21 files to 'c:\Output\MyWorkFlowProject.dll'.

[csc] c:\Projects\MyWorkFlowProject\AProcessFlow.xoml(1,1): error CS0116: A namespace does not directly contain members such as fields or methods

[csc] c:\Projects\MyWorkFlowProject\BProcessFlow.xoml(1,1): error CS0116: A namespace does not directly contain members such as fields or methods

[csc] c:\Projects\MyWorkFlowProject\CProcessFlow.rules(1,1): error CS0116: A namespace does not directly contain members such as fields or methods

[csc] c:\Projects\MyWorkFlowProject\CProcessFlow.xoml(1,1): error CS0116: A namespace does not directly contain members such as fields or methods

+2  A: 

If you check out how Visual Studio/MSBuild compiles a WF project, you will see it requires a lot more.

Therefore, use NAnt to drive MSBuild and compile the Visual Studio project files for you is by far the best and only option.

Lex Li
Agreed. It's easiest to delegate compilation to MSBuild, and NAnt can do everything else. There's more to calling MSBuild than there is to calling the compiler directly.
Grant Palin
That's certainly how I've done it in the past. I was hoping that there would be some considerations added to 0.90 that would enable me to build it using only NAnt.
LockeCJ
I don't want to say NAnt is dead, but it was already dead for me in 2006 or 2007.
Lex Li
It looks like WFC.exe is the command-line tool for compiling .xoml files. I'll use msbuild to compile this project for now, but I'll see if it's possible to accomplish this with NAnt and WFC later.
LockeCJ
A: 

Instead of calling the compiler directly, why not use MSBuild? It handles the compilation, references, etc since it works off the solution file. So the settings in the solution and projects will be used, you don't need to write out the parameters as in your example.

NAnt doesn't have any direct functionality for MSBuild like it does for the compilers; however, NAntContrib has an msbuild task. This is what I use, it makes the compile process very simple in my build script. This is what my compile task looks like:

<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>
Grant Palin
I'm actually calling msbuild from CC.Net to build this particular project for now, since there doesn't seem to be an alternative. My preference for NAnt is actually because it doesn't use the .csproj files. That allows me to create a build configuration that is independent of any changes made to the project files. I think it's a bit more consistent, and less prone to build errors due to unintentional changes to the project files. I'm sure I could accomplish this with msbuild, I'm just far more familiar with NAnt at this point.
LockeCJ
Hi, @LockeCJ, I think not many people choose your preference for NAnt. csproj should be used because your build needs to be in sync with the developers. Keeping both csproj and NAnt script for the same stuffs is horrible to me in the past. I agree that unintentional changes come to csproj files, but why they don't come to your NAnt script? If you have a way to prevent changes to NAnt scripts, I believe there is a way for csproj files, right?
Lex Li
I agree that there is some additional work involved with keeping the NAnt build scripts in sync with the project files, but I think that the consistency is worth it. By keeping them separate, I guarantee that no changes to how the software is built are "accidentally" made. Any changes that are necessitated by changes to the project files can be identified and evaluated before being included. My experience has been different, in that the NAnt files only need occaisional tweaks, but the .csproj files need to be corrected far more often due to Visual studio making machine specific changes.
LockeCJ