This could probably be worked around by using custom property pages for all child elements of tasks. The current implementation is kinda clumsy..I have found the add-in to be good enough for running NAnt builds from Visual Studio, but hardly usable for editing or creating new .build files, or even for getting an overview of how a build file works. The add-in uses the standard Properties window for editing target and task properties, which gives very little space for actual property values. It works especially bad for <fileset> elements - probably the most essential part of a .build file. Just seeing what is in a <fileset> requires expanding three levels in a tree, and adding a new entry to a <fileset> requires about five clicks to different parts of the screen.
Besides that, the current add-in architecture requires manually writingI agree - the wrappers are a big overhead. There was some discussion a while ago as to whether or not the task metadata contains sufficent information for the addin to get what it needs via reflection. I think the consensus was that currently it doesn't. Scott probably remembers the specific better than me.
a wrapper class for every NAnt task class. The wrapper has the same
properties as the NAnt task, and delegates property gets and sets to
the XML node representing the task. Maintaining these wrappers as NAnt
and NAntContrib evolve is quite a major hassle - in fact, I haven't
updated them to match the changes in NAnt core tasks since NAntAddin
was initially developed.
Ian
------------------------------------------------------- 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
