Hi Giuseppe,
I looked at the code of the resgen task, and apparently it's not being
executed on the mono runtime right now.
The following comment is in the UsesRuntimeEngine property :
// TO-DO : uncomment this when monoresgen no longer crashes when run with
the mono runtime.
I think that
Hi Gert,
On Sat, 2003-06-28 at 13:48, Gert Driesen wrote:
Hi Giuseppe,
I looked at the code of the resgen task, and apparently it's not being
executed on the mono runtime right now.
The following comment is in the UsesRuntimeEngine property :
// TO-DO : uncomment this when monoresgen
Its definately in cvs. I've done a clean check out into a seperate
directory and the example below works fine. Are you seeing errors ? What
isn't working ?
Ian
Ian,
On Tue, 2003-06-24 at 11:35, Ian MacLean wrote:
fileset references are done. I still need to add some unit tests and
polish a
On Sat, 2003-06-28 at 16:10, Ian MacLean wrote:
Its definately in cvs. I've done a clean check out into a seperate
directory and the example below works fine. Are you seeing errors ? What
isn't working ?
NAnt simply says Unknown task fileset.
Gius_.
Ian
Ian,
On Tue, 2003-06-24 at
On Sat, 2003-06-28 at 16:15, Ian MacLean wrote:
windows or linux ? - is your fileset definition at the project level ?
fileset definitions at target level are not supported right now.
A-ha, that's the problem... I'm trying to use fileset definitions at
target level...
Gius_.
Ian
On
Guis,
can you run with -verbose. Grab the commandline thats generated and try
it in a shell window. ie see if the same failure occurs when running
monoresgen by itself. If not can you post the full output generated by
nant - including stack trace.
Ian
Hi Gert,
On Sat, 2003-06-28 at 13:48,
cool. I'm just adding support for target level now. Its pretty
straightforward.
Ian
On Sat, 2003-06-28 at 16:15, Ian MacLean wrote:
windows or linux ? - is your fileset definition at the project level ?
fileset definitions at target level are not supported right now.
A-ha, that's the
On Sat, 2003-06-28 at 16:22, Ian MacLean wrote:
Guis,
can you run with -verbose. Grab the commandline thats generated and try
it in a shell window. ie see if the same failure occurs when running
monoresgen by itself. If not can you post the full output generated by
nant - including stack
Hi all,
DocBook source files of the documents Building Projects With NAnt
and C# Coding Guidelines can be checked out from anonymous CVS:
cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/technotes
co building-projects-with-nant csharp-coding-guidelines
They have been compiled on Linux using xsltproc
OK I bit the bullet on this today and copied all the NAntContrib tasks
to a new NAnt.Optional directory under my nant source tree.
I went thru and fixed all the issues Mike mentiond and then some.
Nothing too difficult just lots of find and replace. It all compiles and
the tasks load fine. I'm
How do you propose to deal with the NAntContrib sources ?
will they be moved into /src/NAnt.Optional and /tests/NAnt.Optional or
will they be integrated into the current namespace structure ?
I would still like to get rid of needing a COM interop assembly for
SourceSafe (and if possible also for
Ian,
OK I bit the bullet on this today and copied all the NAntContrib tasks to a
new NAnt.Optional directory under my nant source tree.
I went thru and fixed all the issues Mike mentiond and then some.
Nothing too difficult just lots of find and replace. It all compiles and the
tasks
+1 as if I should have any say in the matter ;)
Ian, this is excellent. You did everything I had dreamed would happen
with NAntContrib and more. I think this is a good move. I was just
sitting down to start looking at what changes were necessary and was
happy to see this post.
I look forward
Not sure about VSS.
Unfortunately the COM Interop for StarTeam is very necessary as it is
the only programmatic interface to their server. Maybe I missed the
point of the desire to be rid of it.
The StarTeam SDK now has an official .NET interop assembly distributed
with their 5.2 SDK. When the
Tomas:
That said, I'd like to take the opportunity to vent something that has
been
nagging me for a while
An excellent description of your frustration, Tomas. I think it is
important for the users of a system to explain to its creators what is
bothering them. I want to make a couple of
Hi William,
As you say, NAnt is not yet at 1.0, isn't it an unrealistic expectation of
us early adopters to use a pre-1.0 release and constrain its developers not
to change the system radically as they learn new things in order to get the
product to 1.0?
I know about this. However, I'd argue
Ian - you're a star - thanks! (and thanks for letting us know before I
was going and do the same thing for some of the tasks. :) )
re: directory tree / namespaces. My own take is that tasks that have
binary dependencies outside of NAnt at least at compile time (e.g.
StarTeam with its interop
Tomas Restrepo wrote:
Ian,
Why optional? If we're gonna move them, you might as well move them right.
For example, some Nant tasks should go into the main Nant builds... Things
like GAC and XSD are fairly common DotNet development operations (I don't
know what criteria you guys are using
Gert Driesen wrote:
How do you propose to deal with the NAntContrib sources ?
will they be moved into /src/NAnt.Optional and /tests/NAnt.Optional or
will they be integrated into the current namespace structure ?
src/NAnt.Optional to start with and move those tasks that fit into NAnt.DotNet or
19 matches
Mail list logo
