Understood. I agree being able to reflect the Tasks to know how to show
stuff would be nice. Unfortunately you still have to use the raw DOM API for
things like cut/copy/paste and such. I've noticed with the NAnt Task API,
anything other than a file set (as child XML elements) you have to write
your own DOM parsing code, so there is no meta data currently in these
cases. It probably wouldn't be too add though.

I also just added an MSITask to NAntContrib. It doesnt write registry
settings or read in the license/logo files but other than that you can build
an install with it (if you get all the XML tags right - I have to document
them). The NAnt script for the Addin uses the task at the bottom of the
file, take a look at it if you want to see an example.

-Jayme

P.S. Yes I will add being able to use wildcards for files instead of having
to type every individual one's filename.

----- Original Message -----
From: "Scott Hernandez" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "'Jayme Edwards'" <[EMAIL PROTECTED]>
Sent: Wednesday, July 17, 2002 2:47 PM
Subject: RE: [nant-dev] Re: Visual Studio.NET Addin initial thoughs


> Yep, the addin should deal directly with the document. But it would be
> nice if the addin could work with existing documents, not just files. :)
> Yet another feature to plug-in later.
>
> I was thinking that instead of created a new class for each type of node
> in the addin we should be able to use a XSD doc/file or reflection
> directly on the task assemblies. That way the addin will always use the
> most up-to-date task definitions, and can automatically work with new
> tasks without any changes to the addin.
>
> For this to work, we really need more meta-data than we have. One of the
> things I want to work on is defining more code attributes that will
> provide this level of meta-data.
>
> [snip]
>
> > One thing I was going to say is that I designed the Addin to access
> the
> > XML document directly, and not using the NAnt API for editing/display.
> The
> > NAnt API is only used for when the build is actually being executed.
> This > may sound like a bad thing at first, but in implementation it
> seems nice
> > because it minimizes the coupling between the NAnt API and the Addin.
> >
> > -Jayme
>



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

Reply via email to