I like the ability to customize any field within the project. Would it be more suitable to perform this modification using the <xmlpeek>/<xmlpoke> tasks outside of the solution task itself?

Perhaps some sort of per-project handler subtask could work as well:

<solution ...>
<projects> ... </projects>
<projecthandlers>
<projecthandler execute="before" match="**/*.csproj" property="input.file">
<xmlpoke file="${input.file}" xpath="VisualStudioProject/CSHARP/Build/Settings/@DelaySign" value="True" />
</projecthandler>
</projecthandlers>
</solution>


I love the ability to do per-project customization. The above would allow us to re-use some existing tasks (and perhaps perform more complex project manipulation!).

How does this sound?


Jaroslaw Kowalski wrote:
Some time ago I proposed a syntax to allow the ultimate customization of
<solution> task.
It was something like:

<solution configuration="Release" outputdir="${output.dir}"
includevsfolders="false" showcommands="true">
    <projects>
         <includes name="${build.dir}/**/*.csproj"/>
    </projects>

    <override project="*.csproj">
        <param name="VisualStudioProject/CSHARP/Build/Settings/@DelaySign"
value="True" />
         <override file="File1.cs">
                <param name="@BuildAction" value="Compile" />
        </override>
    </override>

    <override project="**/Project1/*.csproj">
        <compiler-args>/codepage:1250</compiler-args>
    </override>
</solution>

Each <override> would be processed after the project is loaded into memory
and it matches the "project" attribute. The algorithm would be:

1. For each <param>, find the XML node specified by "name" XPath attribute
2. Set the value of this node as specified in "value" attribute

The idea is simple, yet allows for ultimate extensibility. Perhaps we might
even think about adding / removing items specified by XPath.
For parameters, that aren't there in the *.csproj file we'd have special
tags, like <compiler-args> mentioned above.

Applications:

1. To override some flag in all C# projects, you use: <override
project="**/*.csproj" />
2. To override some flag in all VB projects, you use: <override
project="**/*.vbproj" />
3. To override some flag in all VB projects, you use: <override
project="**/*.vcproj" />
4. To exclude some file from compilation, use:

         <override file="File1.cs">
                <param name="@BuildAction" value="Content" />
        </override>

What do you think ?

Jarke

----- Original Message ----- From: "Matthew Mastracci" <[EMAIL PROTECTED]>
To: "Nant-Developers (E-mail)" <[EMAIL PROTECTED]>
Sent: Tuesday, January 06, 2004 7:27 PM
Subject: [nant-dev] [Fwd: [Nprof-developers] Re: solution task]





-------- Original Message -------- Subject: [Nprof-developers] Re: solution task Date: Tue, 06 Jan 2004 11:09:22 -0700 From: Matthew Mastracci <[EMAIL PROTECTED]> To: Martin Aliger <[EMAIL PROTECTED]>, [EMAIL PROTECTED] References: <[EMAIL PROTECTED]>

Sounds good to me too - just ensure that you've got compilerargs
specified by language.  There's a number of flags that are valid for a
single compiler only.

Martin Aliger wrote:


Hi all !

1/
Do you think, that now is good time to some cleaning and restructuring
in solution task as we discussed earlier? I have some spare time and
appetite to do that now!

2/
Also I would need (and like to) make some improvements to that task.
What I need (and currently use not-commited patch) is need to custom
arguments override like there:

<solution configuration="Release" outputdir="${output.dir}"
includevsfolders="false" showcommands="true">
  <projects>
   <includes name="${build.dir}/**/*.csproj"/>
  </projects>
  <assemblyfolders>
   <includes name="${output.dir}"/>
   <includes name="${nunit.dir}"/>
   <includes name="${references.dir}"/>
  </assemblyfolders>
  <compilerargs>
   <arg value="/codepage:1250"/>
  </compilerargs>
</solution>
We previously discuss that as it will be nice to do that at solution
level or at project level. Do you still like the idea? I could implement
that if you agree with that...

Regards,
Martin




------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Nprof-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nprof-developers




------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers





-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click



------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers

Reply via email to