[nant-dev] regex task
Hi all,
What is good at
[StringValidator(AllowEmpty=false)]
in input parameter of regex? Why input could not be empty? I see no reason
there.
For example:
regex pattern=^(?'changes'.*) $ input=${changes}/
This cut of last space from changes property. If changes is accidentally
empty, no cut is performed. But recent change in StringValidator disable
such use of regex, and build fails (even with failonerror=false! )
Martin
regex.patch
Description: Binary data
Re: [nant-dev] Framework 1.0 dependency in ConsoleStub.cs
Another way is to write a custom utility task that takes the config file
and if the default framework doesn't match
nant.settings.currentframework it creates a copy with a specified name
and with the defaultconfig setting updated.
checknantconfig fromconfig=${nant.location}nant.exe.config
toconfig=${nant.location}nant.tests.config /
then the nunit task would be defined like:
nunit2
formatter type=Plain /
test
assemblyname=${build.dir}/bin/${nant.project.name}.Tests.dll
appconfig=${nant.location}nant.tests.config /
/nunit2
the checknantconfig task ( we can work on the name ) wouldn't ship with
nant it would just be a utility task that we load with nanttasks.
this way we don't have to hack the nunittask.
What do you think ?
Ian
I've written a quick hack to generate a new config file in the temp
folder with the default framework set to what was passed in -k, and then
passes that config to the tests. This works but its not the 'right'
solution because its in the NUnitTask.cs and will try and run for every
test task - not just the tests for nant.
I don't think we'd want that ...
This will do in a pinch as it will solve the problem without too much
overhead, but I'm haveing a look at alternatives.
I'll think about it too, ...
Gert
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] solution task addin
Hi all,
Again, I propose an
addin into solution task. It enables use of extra parameters for csc task as in
this case:
solution
configuration="Release" outputdir="${output.dir}"
includevsfolders="false"
projects
includes
name="${build.dir}/**/*.csproj"/
/projects
assemblyfolders
includes
name="${output.dir}"/
includes name="${nunit.dir}"/
/assemblyfolders arg
value="/codepage:1250"//solution
adding extra /codepage:1250
to csc calls. This is needed, when .cs files
are in another codepage than ascii, unicode or utf-8.
This could be used for other switches as well! Hope you'll
like it :)
Martin
solutiontask.patch
Description: Binary data
Re: [nant-dev] solution task addin
use BuildElementCollection(compilerargument or compilerargs) instead
of [BuildElementArray(arg)]
Ok. I'll rework it.
PS. can you also change your code format to use brackets on the same line,
instead of on the next line ...
sorry for that. I was trying hard, but we use different code convention here
(similar to VS default) to I sometimes forget it...
- Original Message -
From: Gert Driesen
To: Martin Aliger ; ! nant
Sent: Friday, September 12, 2003 1:08 PM
Subject: Re: [nant-dev] solution task addin
Look very good, but I have some remarks :
use BuildElementCollection(compilerargument or compilerargs) instead of
[BuildElementArray(arg)]
that will :
- make it clear that those are argument that will be passed to the compiler
- allow us to use a more structured build layout
solution ...
projects ...
...
/project
compilerarguments | compilerargs
arg value=. /
arg value= /
/compilerarguments | /compilerargs
/solution
why not rename GetCSCArguments to GetCompilerArguments, as these arguments
will also be useful for other compilers (VB.NET).
Keep up the good work !!!
Gert
PS. can you also change your code format to use brackets on the same line,
instead of on the next line ...
- Original Message -
From: Martin Aliger
To: ! nant
Sent: Friday, September 12, 2003 11:35 AM
Subject: [nant-dev] solution task addin
Hi all,
Again, I propose an addin into solution task. It enables use of extra
parameters for csc task as in this case:
solution configuration=Release outputdir=${output.dir}
includevsfolders=false
projects
includes name=${build.dir}/**/*.csproj/
/projects
assemblyfolders
includes name=${output.dir}/
includes name=${nunit.dir}/
/assemblyfolders
arg value=/codepage:1250/
/solution
adding extra /codepage:1250 to csc calls. This is needed, when .cs files are
in another codepage than ascii, unicode or utf-8.
This could be used for other switches as well! Hope you'll like it :)
Martin
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] solution task addin
Here it is reworked. Looks much nicer now :)
solution configuration=Release outputdir=${output.dir}
includevsfolders=false
projects
includes name=${build.dir}/**/*.csproj/
/projects
assemblyfolders
includes name=${output.dir}/
includes name=${nunit.dir}/
/assemblyfolders
compilerargs
arg value=/codepage:1250/
/compilerargs
/solution
Martin
- Original Message -
From: Martin Aliger [EMAIL PROTECTED]
To: Gert Driesen [EMAIL PROTECTED]; ! nant
[EMAIL PROTECTED]
Sent: Friday, September 12, 2003 1:08 PM
Subject: Re: [nant-dev] solution task addin
use BuildElementCollection(compilerargument or compilerargs) instead
of [BuildElementArray(arg)]
Ok. I'll rework it.
PS. can you also change your code format to use brackets on the same
line,
instead of on the next line ...
sorry for that. I was trying hard, but we use different code convention
here
(similar to VS default) to I sometimes forget it...
- Original Message -
From: Gert Driesen
To: Martin Aliger ; ! nant
Sent: Friday, September 12, 2003 1:08 PM
Subject: Re: [nant-dev] solution task addin
Look very good, but I have some remarks :
use BuildElementCollection(compilerargument or compilerargs) instead
of
[BuildElementArray(arg)]
that will :
- make it clear that those are argument that will be passed to the
compiler
- allow us to use a more structured build layout
solution ...
projects ...
...
/project
compilerarguments | compilerargs
arg value=. /
arg value= /
/compilerarguments | /compilerargs
/solution
why not rename GetCSCArguments to GetCompilerArguments, as these arguments
will also be useful for other compilers (VB.NET).
Keep up the good work !!!
Gert
PS. can you also change your code format to use brackets on the same line,
instead of on the next line ...
- Original Message -
From: Martin Aliger
To: ! nant
Sent: Friday, September 12, 2003 11:35 AM
Subject: [nant-dev] solution task addin
Hi all,
Again, I propose an addin into solution task. It enables use of extra
parameters for csc task as in this case:
solution configuration=Release outputdir=${output.dir}
includevsfolders=false
projects
includes name=${build.dir}/**/*.csproj/
/projects
assemblyfolders
includes name=${output.dir}/
includes name=${nunit.dir}/
/assemblyfolders
arg value=/codepage:1250/
/solution
adding extra /codepage:1250 to csc calls. This is needed, when .cs files
are
in another codepage than ascii, unicode or utf-8.
This could be used for other switches as well! Hope you'll like it :)
Martin
solutiontask.patch
Description: Binary data
Re: [nant-dev] solution task addin
Look very good, but I have some remarks
:
use
BuildElementCollection("compilerargument"or "compilerargs") instead of
[BuildElementArray("arg")]
that will :
- make it clear that those are argument that will
be passed to the compiler
- allow us to use a more structured build layout
solution ...
projects
...
...
/project
compilerarguments |
compilerargs
arg
value="." /
arg
value="" /
/compilerarguments |
/compilerargs
/solution
why not rename GetCSCArguments to
GetCompilerArguments, as these arguments will also be useful for other compilers
(VB.NET).
Keep up the good work !!!
Gert
PS.can you also
change your code format to use brackets on the same line, instead of on the next
line ...
- Original Message -
From:
Martin
Aliger
To: ! nant
Sent: Friday, September 12, 2003 11:35
AM
Subject: [nant-dev] solution task
addin
Hi all,
Again, I propose
an addin into solution task. It enables use of extra parameters for csc task
as in this case:
solution
configuration="Release" outputdir="${output.dir}"
includevsfolders="false"
projects
includes
name="${build.dir}/**/*.csproj"/
/projects
assemblyfolders
includes
name="${output.dir}"/
includes name="${nunit.dir}"/
/assemblyfolders arg
value="/codepage:1250"//solution
adding extra /codepage:1250
to csc calls. This is needed, when .cs
files are in another codepage than ascii, unicode or
utf-8.
This could be used for other switches as well! Hope you'll
like it :)
Martin
Re: [nant-dev] solution task addin
I'll commit it later today.
Thanks,
Gert
- Original Message -
From: Martin Aliger [EMAIL PROTECTED]
To: ! nant [EMAIL PROTECTED]
Sent: Friday, September 12, 2003 2:04 PM
Subject: Re: [nant-dev] solution task addin
Here it is reworked. Looks much nicer now :)
solution configuration=Release outputdir=${output.dir}
includevsfolders=false
projects
includes name=${build.dir}/**/*.csproj/
/projects
assemblyfolders
includes name=${output.dir}/
includes name=${nunit.dir}/
/assemblyfolders
compilerargs
arg value=/codepage:1250/
/compilerargs
/solution
Martin
- Original Message -
From: Martin Aliger [EMAIL PROTECTED]
To: Gert Driesen [EMAIL PROTECTED]; ! nant
[EMAIL PROTECTED]
Sent: Friday, September 12, 2003 1:08 PM
Subject: Re: [nant-dev] solution task addin
use BuildElementCollection(compilerargument or compilerargs)
instead
of [BuildElementArray(arg)]
Ok. I'll rework it.
PS. can you also change your code format to use brackets on the same
line,
instead of on the next line ...
sorry for that. I was trying hard, but we use different code convention
here
(similar to VS default) to I sometimes forget it...
- Original Message -
From: Gert Driesen
To: Martin Aliger ; ! nant
Sent: Friday, September 12, 2003 1:08 PM
Subject: Re: [nant-dev] solution task addin
Look very good, but I have some remarks :
use BuildElementCollection(compilerargument or compilerargs) instead
of
[BuildElementArray(arg)]
that will :
- make it clear that those are argument that will be passed to the
compiler
- allow us to use a more structured build layout
solution ...
projects ...
...
/project
compilerarguments | compilerargs
arg value=. /
arg value= /
/compilerarguments | /compilerargs
/solution
why not rename GetCSCArguments to GetCompilerArguments, as these
arguments
will also be useful for other compilers (VB.NET).
Keep up the good work !!!
Gert
PS. can you also change your code format to use brackets on the same
line,
instead of on the next line ...
- Original Message -
From: Martin Aliger
To: ! nant
Sent: Friday, September 12, 2003 11:35 AM
Subject: [nant-dev] solution task addin
Hi all,
Again, I propose an addin into solution task. It enables use of extra
parameters for csc task as in this case:
solution configuration=Release outputdir=${output.dir}
includevsfolders=false
projects
includes name=${build.dir}/**/*.csproj/
/projects
assemblyfolders
includes name=${output.dir}/
includes name=${nunit.dir}/
/assemblyfolders
arg value=/codepage:1250/
/solution
adding extra /codepage:1250 to csc calls. This is needed, when .cs files
are
in another codepage than ascii, unicode or utf-8.
This could be used for other switches as well! Hope you'll like it :)
Martin
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] solution task addin
Quick note- should the compiler be specified for each of these args?
Not all args are supported by all compilers. Specifying an argument
that a compiler does not support may break your build. I'd wager that a
good number of places used mixed-language builds.
BTW, thanks for all of the patches Martin!
Perhaps something like this (I'm not sure if using the language name
(C#) or the compiler (csc) would be better):
compilerargs compiler=C#
arg value=/codepage:1250/
/compilerargs
compilerargs compiler=VB
arg value=/defaultnamespace:blah/
/compilerargs
Or this:
compilerargs
arg compiler=C# value=/codepage:1250/
arg compiler=VB value=/defaultnamespace:blah/
/compilerargs
Matt.
Gert Driesen wrote:
I'll commit it later today.
Thanks,
Gert
- Original Message -
From: Martin Aliger [EMAIL PROTECTED]
To: ! nant [EMAIL PROTECTED]
Sent: Friday, September 12, 2003 2:04 PM
Subject: Re: [nant-dev] solution task addin
Here it is reworked. Looks much nicer now :)
solution configuration=Release outputdir=${output.dir}
includevsfolders=false
projects
includes name=${build.dir}/**/*.csproj/
/projects
assemblyfolders
includes name=${output.dir}/
includes name=${nunit.dir}/
/assemblyfolders
compilerargs
arg value=/codepage:1250/
/compilerargs
/solution
Martin
- Original Message -
From: Martin Aliger [EMAIL PROTECTED]
To: Gert Driesen [EMAIL PROTECTED]; ! nant
[EMAIL PROTECTED]
Sent: Friday, September 12, 2003 1:08 PM
Subject: Re: [nant-dev] solution task addin
use BuildElementCollection(compilerargument or compilerargs)
instead
of [BuildElementArray(arg)]
Ok. I'll rework it.
PS. can you also change your code format to use brackets on the same
line,
instead of on the next line ...
sorry for that. I was trying hard, but we use different code convention
here
(similar to VS default) to I sometimes forget it...
- Original Message -
From: Gert Driesen
To: Martin Aliger ; ! nant
Sent: Friday, September 12, 2003 1:08 PM
Subject: Re: [nant-dev] solution task addin
Look very good, but I have some remarks :
use BuildElementCollection(compilerargument or compilerargs) instead
of
[BuildElementArray(arg)]
that will :
- make it clear that those are argument that will be passed to the
compiler
- allow us to use a more structured build layout
solution ...
projects ...
...
/project
compilerarguments | compilerargs
arg value=. /
arg value= /
/compilerarguments | /compilerargs
/solution
why not rename GetCSCArguments to GetCompilerArguments, as these
arguments
will also be useful for other compilers (VB.NET).
Keep up the good work !!!
Gert
PS. can you also change your code format to use brackets on the same
line,
instead of on the next line ...
- Original Message -
From: Martin Aliger
To: ! nant
Sent: Friday, September 12, 2003 11:35 AM
Subject: [nant-dev] solution task addin
Hi all,
Again, I propose an addin into solution task. It enables use of extra
parameters for csc task as in this case:
solution configuration=Release outputdir=${output.dir}
includevsfolders=false
projects
includes name=${build.dir}/**/*.csproj/
/projects
assemblyfolders
includes name=${output.dir}/
includes name=${nunit.dir}/
/assemblyfolders
arg value=/codepage:1250/
/solution
adding extra /codepage:1250 to csc calls. This is needed, when .cs files
are
in another codepage than ascii, unicode or utf-8.
This could be used for other switches as well! Hope you'll like it :)
Martin
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] Re: foreach
Here is patch to correct this. Not sure whether
rather do not remove trim from ConvertEmptyToNull and
IsNullOrEmpty.
Martin
- Original Message -
From:
Martin
Aliger
To: ! nant
Sent: Friday, September 12, 2003 12:05
PM
Subject: foreach
Hi all,
foreach
item="String" in="${changes}" delim=" " property="folder"
is no longer valid in recent cvs version. This is
becouse of
public
string Delimiter {
get { return _delim; }
set { _delim =
StringUtils.ConvertEmptyToNull(value);}
}
and
ConvertEmptyToNull does trimming into its value. So
delimiter is null and
throw new BuildException(@"Delimiter must
be specified for item=""String""");
is thrown :-(
I think, this _is_ legal statement
though.
Martin
foreach.patch
Description: Binary data
Re: [nant-dev] solution task addin
Personally I think it's a bad idea to have extensions like this because they
change semantics of solution task from something very simple (do it like
VS.NET does) to something quite difficult to follow.
I've made a quick scan through all csc.exe options that cannot be set in
VS.NET by searching through MSDN for This compiler option is unavailable in
Visual Studio.. And I see only four options that might be useful to add
this way:
/utf8output
/noconfig
/codepage
/fullpaths
any other options (there are 14 which aren't settable through VS.NET) don't
make sense since they would change the semantics of the build or aren't
usable with NAnt.
I vote against the patch.
Martin, if you have problems with the codepage - use UTF-8 for source files
or change your system locale. The best way would be to move all
language-specific elements to a separate resource XML file (*.resx) because
XML files preserve encoding informations.
To save your file as UTF-8:
VS.NET = File = Advanced Save Options = Encoding = Unicode (UTF-8 with
signature)
Jarek
- Original Message -
From: Gert Driesen [EMAIL PROTECTED]
To: Martin Aliger [EMAIL PROTECTED]; ! nant
[EMAIL PROTECTED]
Sent: Friday, September 12, 2003 2:19 PM
Subject: Re: [nant-dev] solution task addin
I'll commit it later today.
Thanks,
Gert
- Original Message -
From: Martin Aliger [EMAIL PROTECTED]
To: ! nant [EMAIL PROTECTED]
Sent: Friday, September 12, 2003 2:04 PM
Subject: Re: [nant-dev] solution task addin
Here it is reworked. Looks much nicer now :)
solution configuration=Release outputdir=${output.dir}
includevsfolders=false
projects
includes name=${build.dir}/**/*.csproj/
/projects
assemblyfolders
includes name=${output.dir}/
includes name=${nunit.dir}/
/assemblyfolders
compilerargs
arg value=/codepage:1250/
/compilerargs
/solution
Martin
- Original Message -
From: Martin Aliger [EMAIL PROTECTED]
To: Gert Driesen [EMAIL PROTECTED]; ! nant
[EMAIL PROTECTED]
Sent: Friday, September 12, 2003 1:08 PM
Subject: Re: [nant-dev] solution task addin
use BuildElementCollection(compilerargument or compilerargs)
instead
of [BuildElementArray(arg)]
Ok. I'll rework it.
PS. can you also change your code format to use brackets on the same
line,
instead of on the next line ...
sorry for that. I was trying hard, but we use different code
convention
here
(similar to VS default) to I sometimes forget it...
- Original Message -
From: Gert Driesen
To: Martin Aliger ; ! nant
Sent: Friday, September 12, 2003 1:08 PM
Subject: Re: [nant-dev] solution task addin
Look very good, but I have some remarks :
use BuildElementCollection(compilerargument or compilerargs)
instead
of
[BuildElementArray(arg)]
that will :
- make it clear that those are argument that will be passed to the
compiler
- allow us to use a more structured build layout
solution ...
projects ...
...
/project
compilerarguments | compilerargs
arg value=. /
arg value= /
/compilerarguments | /compilerargs
/solution
why not rename GetCSCArguments to GetCompilerArguments, as these
arguments
will also be useful for other compilers (VB.NET).
Keep up the good work !!!
Gert
PS. can you also change your code format to use brackets on the same
line,
instead of on the next line ...
- Original Message -
From: Martin Aliger
To: ! nant
Sent: Friday, September 12, 2003 11:35 AM
Subject: [nant-dev] solution task addin
Hi all,
Again, I propose an addin into solution task. It enables use of extra
parameters for csc task as in this case:
solution configuration=Release outputdir=${output.dir}
includevsfolders=false
projects
includes name=${build.dir}/**/*.csproj/
/projects
assemblyfolders
includes name=${output.dir}/
includes name=${nunit.dir}/
/assemblyfolders
arg value=/codepage:1250/
/solution
adding extra /codepage:1250 to csc calls. This is needed, when .cs
files
are
in another codepage than ascii, unicode or utf-8.
This could be used for other switches as well! Hope you'll like it :)
Martin
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
nant-developers mailing list
[EMAIL PROTECTED]
Re: [nant-dev] Re: foreach
Good catch again, martin.
It would be even better if you could also creates
unit tests for the fixes you post :-)
Gert
- Original Message -
From:
Martin
Aliger
To: ! nant
Sent: Friday, September 12, 2003 2:01
PM
Subject: [nant-dev] Re: foreach
Here is patch to correct this. Not sure whether
rather do not remove trim from ConvertEmptyToNull and
IsNullOrEmpty.
Martin
- Original Message -
From:
Martin Aliger
To: ! nant
Sent: Friday, September 12, 2003 12:05
PM
Subject: foreach
Hi all,
foreach
item="String" in="${changes}" delim=" "
property="folder"
is no longer valid in recent cvs version. This
is becouse of
public
string Delimiter {
get { return _delim; }
set { _delim =
StringUtils.ConvertEmptyToNull(value);}
}
and
ConvertEmptyToNull does trimming into its value. So
delimiter is null and
throw new BuildException(@"Delimiter must
be specified for item=""String""");
is thrown :-(
I think, this _is_ legal statement
though.
Martin
Re: [nant-dev] Re: foreach
It would be even better if you could also creates unit tests for the fixes you post :-) Oh. It would be great. I'm writing huge amount of test cases for our company now so this should not be a problem. I'll look how nant tests work and next patch will be with test case :) Martin --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] solution task addin
I agree with Martin. Sometimes you need to override a build setting on
your build machine. At our shop, we tag each build with a string
version that doesn't fit Microsoft's idea of a version number. This
produces a warning and, on assemblies that build with warning = error, a
build failure!
It's easier for us to add the /nowarn: flag on each assembly at build
time, rather than at development time (imagine adding this flag to 75 C#
projects :)).
The solution task was never designed to operate specifically like
VS.NET, but rather with the ability to build VS.NET compatible files and
offering a great deal more functionality. This makes up for the lack of
functionality that Microsoft has given VS.NET's build process. I'm all
for adding any functionality that allows me to customize my build further.
See this link for some more info:
http://nant.sourceforge.net/wiki/index.php/SolutionTask
Martin Aliger wrote:
Hi Jarek,
Personally I think it's a bad idea to have extensions like this because
they
change semantics of solution task from something very simple (do it like
VS.NET does) to something quite difficult to follow.
Maybe you need to build exacly what solution says. But I need to override
some settings. For example output path (outputdir attribute). This overrides
something, which is in .csproj. It is handy in some situations. For the same
reason could be handy to specify other compiler options. Good point by Matt,
that it could be specified by compiler (c#/vb), though.
As I see solution task, it is something that take vs solutions or projects
and integrate it into nant. Level on which you integrate should be
adjustable. Someone want to just build that solution file (build win project
on Linux without vs), someone want to use just file list from csproj and
override all other options. IMHO current implementation fullfil this idea
(to some extent).
I've made a quick scan through all csc.exe options that cannot be set in
VS.NET by searching through MSDN for This compiler option is unavailable
in
Visual Studio.. And I see only four options that might be useful to add
this way:
/utf8output
/noconfig
/codepage
/fullpaths
any other options (there are 14 which aren't settable through VS.NET)
don't
make sense since they would change the semantics of the build or aren't
usable with NAnt.
True. There could be more options in future, or more options in another
compiler (mono) and you want to use it for some reason. Why update .csproj
when you could update .build file? For build servers where csprojs are
submitted by developes you will need to read and change their csprojs. I do
not like this much...
I vote against the patch.
Martin, if you have problems with the codepage - use UTF-8 for source
files
or change your system locale. The best way would be to move all
language-specific elements to a separate resource XML file (*.resx)
because
XML files preserve encoding informations.
To save your file as UTF-8:
VS.NET = File = Advanced Save Options = Encoding = Unicode (UTF-8 with
signature)
Oh. Thanks! I do not know about this vs feature. resx havn't problem with
this, but embedded xmldoc have :-(.
Martin
Jarek
- Original Message -
From: Gert Driesen [EMAIL PROTECTED]
To: Martin Aliger [EMAIL PROTECTED]; ! nant
[EMAIL PROTECTED]
Sent: Friday, September 12, 2003 2:19 PM
Subject: Re: [nant-dev] solution task addin
I'll commit it later today.
Thanks,
Gert
- Original Message -
From: Martin Aliger [EMAIL PROTECTED]
To: ! nant [EMAIL PROTECTED]
Sent: Friday, September 12, 2003 2:04 PM
Subject: Re: [nant-dev] solution task addin
Here it is reworked. Looks much nicer now :)
solution configuration=Release outputdir=${output.dir}
includevsfolders=false
projects
includes name=${build.dir}/**/*.csproj/
/projects
assemblyfolders
includes name=${output.dir}/
includes name=${nunit.dir}/
/assemblyfolders
compilerargs
arg value=/codepage:1250/
/compilerargs
/solution
Martin
- Original Message -
From: Martin Aliger [EMAIL PROTECTED]
To: Gert Driesen [EMAIL PROTECTED]; ! nant
[EMAIL PROTECTED]
Sent: Friday, September 12, 2003 1:08 PM
Subject: Re: [nant-dev] solution task addin
use BuildElementCollection(compilerargument or compilerargs)
instead
of [BuildElementArray(arg)]
Ok. I'll rework it.
PS. can you also change your code format to use brackets on the
same
line,
instead of on the next line ...
sorry for that. I was trying hard, but we use different code
convention
here
(similar to VS default) to I sometimes forget it...
- Original Message -
From: Gert Driesen
To: Martin Aliger ; ! nant
Sent: Friday, September 12, 2003 1:08 PM
Subject: Re: [nant-dev] solution task addin
Look very good, but I have some remarks :
use BuildElementCollection(compilerargument or compilerargs)
Re: [nant-dev] solution task addin
Hi Jarek,
Personally I think it's a bad idea to have extensions like this because
they
change semantics of solution task from something very simple (do it like
VS.NET does) to something quite difficult to follow.
Maybe you need to build exacly what solution says. But I need to override
some settings. For example output path (outputdir attribute). This overrides
something, which is in .csproj. It is handy in some situations. For the same
reason could be handy to specify other compiler options. Good point by Matt,
that it could be specified by compiler (c#/vb), though.
As I see solution task, it is something that take vs solutions or projects
and integrate it into nant. Level on which you integrate should be
adjustable. Someone want to just build that solution file (build win project
on Linux without vs), someone want to use just file list from csproj and
override all other options. IMHO current implementation fullfil this idea
(to some extent).
I've made a quick scan through all csc.exe options that cannot be set in
VS.NET by searching through MSDN for This compiler option is unavailable
in
Visual Studio.. And I see only four options that might be useful to add
this way:
/utf8output
/noconfig
/codepage
/fullpaths
any other options (there are 14 which aren't settable through VS.NET)
don't
make sense since they would change the semantics of the build or aren't
usable with NAnt.
True. There could be more options in future, or more options in another
compiler (mono) and you want to use it for some reason. Why update .csproj
when you could update .build file? For build servers where csprojs are
submitted by developes you will need to read and change their csprojs. I do
not like this much...
I vote against the patch.
Martin, if you have problems with the codepage - use UTF-8 for source
files
or change your system locale. The best way would be to move all
language-specific elements to a separate resource XML file (*.resx)
because
XML files preserve encoding informations.
To save your file as UTF-8:
VS.NET = File = Advanced Save Options = Encoding = Unicode (UTF-8 with
signature)
Oh. Thanks! I do not know about this vs feature. resx havn't problem with
this, but embedded xmldoc have :-(.
Martin
Jarek
- Original Message -
From: Gert Driesen [EMAIL PROTECTED]
To: Martin Aliger [EMAIL PROTECTED]; ! nant
[EMAIL PROTECTED]
Sent: Friday, September 12, 2003 2:19 PM
Subject: Re: [nant-dev] solution task addin
I'll commit it later today.
Thanks,
Gert
- Original Message -
From: Martin Aliger [EMAIL PROTECTED]
To: ! nant [EMAIL PROTECTED]
Sent: Friday, September 12, 2003 2:04 PM
Subject: Re: [nant-dev] solution task addin
Here it is reworked. Looks much nicer now :)
solution configuration=Release outputdir=${output.dir}
includevsfolders=false
projects
includes name=${build.dir}/**/*.csproj/
/projects
assemblyfolders
includes name=${output.dir}/
includes name=${nunit.dir}/
/assemblyfolders
compilerargs
arg value=/codepage:1250/
/compilerargs
/solution
Martin
- Original Message -
From: Martin Aliger [EMAIL PROTECTED]
To: Gert Driesen [EMAIL PROTECTED]; ! nant
[EMAIL PROTECTED]
Sent: Friday, September 12, 2003 1:08 PM
Subject: Re: [nant-dev] solution task addin
use BuildElementCollection(compilerargument or compilerargs)
instead
of [BuildElementArray(arg)]
Ok. I'll rework it.
PS. can you also change your code format to use brackets on the
same
line,
instead of on the next line ...
sorry for that. I was trying hard, but we use different code
convention
here
(similar to VS default) to I sometimes forget it...
- Original Message -
From: Gert Driesen
To: Martin Aliger ; ! nant
Sent: Friday, September 12, 2003 1:08 PM
Subject: Re: [nant-dev] solution task addin
Look very good, but I have some remarks :
use BuildElementCollection(compilerargument or compilerargs)
instead
of
[BuildElementArray(arg)]
that will :
- make it clear that those are argument that will be passed to the
compiler
- allow us to use a more structured build layout
solution ...
projects ...
...
/project
compilerarguments | compilerargs
arg value=. /
arg value= /
/compilerarguments | /compilerargs
/solution
why not rename GetCSCArguments to GetCompilerArguments, as these
arguments
will also be useful for other compilers (VB.NET).
Keep up the good work !!!
Gert
PS. can you also change your code format to use brackets on the same
line,
instead of on the next line ...
- Original Message -
From: Martin Aliger
To: ! nant
Sent: Friday, September 12, 2003 11:35 AM
[nant-dev] foreach
Hi all,
foreach item="String"
in="${changes}" delim=" " property="folder"
is no longer valid in recent cvs version. This is
becouse of
public
string Delimiter {
get
{ return _delim; }
set
{ _delim =
StringUtils.ConvertEmptyToNull(value);}
}
and
ConvertEmptyToNull does trimming into its value. So
delimiter is null and
throw new BuildException(@"Delimiter must be
specified for item=""String""");
is thrown :-(
I think, this _is_ legal statement
though.
Martin
RE: [nant-dev] Framework 1.0 dependency in ConsoleStub.cs
OK whats happening is that we pass a config file to our test
assemblies.
This config file will have the default set to 1.0 causing problems
when
the test initialises.
There is currently no easy way of passing the -k value thru to the
tests
as they are standalone test assemblies that could be run from the
NUnitConsole rather than the NUnit task.
I've written a quick hack to generate a new config file in the temp
folder with the default framework set to what was passed in -k, and
then
passes that config to the tests. This works but its not the 'right'
solution because its in the NUnitTask.cs and will try and run for
every
test task - not just the tests for nant.
I don't think we'd want that ...
It might, however, explain/fix the NUnit2 task problem that I have with
tests that rely upon config files. The tests that expect
Some.Assembly.Name.dll.config to be adjacent to the assembly fail
because the 1.0 Framework is unavailable on my build machine. If I run
the NUnit-Console or NUnit-GUI against the assembly directly, it works
just fine.
NAnt.exe.config already has the 1.1 default and proper ordering of the
supportedRuntimes... :\ Something's preventing proper loading of the
config file due to some M$ change in the XML namespaces.
Here's an example test that fails under NAnt that runs fine using
NUnit-Console directly. It seems to fail because the config file is not
loaded (leaving the connection strings and other values null). I wrote
this little stub test for this demonstration:
[Test()]
public void TestConfig()
{
Assertion.AssertEquals( These must match.,
ConfigurationSettings.AppSettings[Config Test],
Nunya );
}
// NAnt runs.
unittests:
[echo] Run the unit tests.
[nunit2] Tests run: 9, Failures: 1, Not run: 0, Time: 0.1301924
seconds
Failures:
1)
eRealty.Desktop.AppointmentCalendar.TestCalendarUserControl.TestConfig :
Thes
e must match.
expected:(null)
but was:Nunya
at
eRealty.Desktop.AppointmentCalendar.TestCalendarUserControl.TestConfig()
i
n c:\build\desktop\appointmentcalendar\Calendar.ascx.cs:line 48
Total time: 8 seconds.
BUILD FAILED
Tests Failed
// NUnit-Console runs.
C:\buildC:\Program Files\NUnit V2.0\bin\nunit-console
/assembly:desktop\bin\e
realty.desktop.appointmentcalendar.dll
NUnit version 2.0.6
Copyright (C) 2002 James W. Newkirk, Michael C. Two, Alexei A.
Vorontsov.
Copyright (C) 2000-2002 Philip Craig.
All Rights Reserved.
..N.N.N.N.N.N
Tests run: 9, Failures: 0, Not run: 0, Time: 0.1902812 seconds
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
