[nant-dev] XML Schema Validated Tasks
Hello, There are two "issues" I've run into with NAnt recently. The first of these is that when I wrote the VS.NET addin, I ended up writing TaskNode classes that wrap each Task. This caused me to run into a host of problems because there isn't enough metadata on a Task to state what attributes are required under what conditions and how to access child XML elements of a task (other than ones that represent a fileset) in a standard way. When I first contributed the Addin, many of you remarked on how it would be nicer if we had more metadata so that each time a new drop of NAnt comes out or a new task is available, the addin is updated to show the correct property editors etc. The second of these is that when I wrote the MSI task (in NAntContrib), the amount of error cases became horrendous. I had several XML elements that are nested and should have unique "name" attributes, and other XML elements that refer to those previously defined names. To make a long story short, I've added a .NET attribute "SchemaValidator" that when applied to a Task class forces it to validate itself against an XML Schema prior to being executed in an NAnt target. To use this, you need to do the following: -Create a Task that inherits from NAnt.Contrib.Tasks.SchemaValidatedTask. -Write an XML Schema for the Task. Make the targetNamespace the same as the name of the Task's class. -Place the XML Schema (.xsd) in the same directory as your Task's source. -Add a xsd target to the NAntContrib compile.schemas target to compile your schema. This gets precompiled into NAnt.Contrib.Schemas.dll, which gets deleted after the Tasks are built. (The compiled schemas get stored in the Task's assembly). -Add a using statement to the task you created in the first step to declare the compiled schema's C# namespace -Add a [TaskValidator(type)] attribute that takes the Type of the root element of your task as generated by xsd. -In InitializeTask(), call base.InitializeTask(TaskNode) and then retrieve the SchemaObject property. This will return the class xsd generated for the root element of your task's schema populated with values from the currently running task. What does this buy you? -Error messages with the line number that describe invalid elements, attributes, or relationships in a task -Ability to make sure XML matches criteria prior to execution (reduce error handling code) -Ability to get a C# object model that wraps your task's data instead of using XmlElement.SelectSingleNode. -Ability to validate an entire NAnt project prior to executing the first task in the future, if we had a schema for NAnt. -Ability to use the System.Xml.Schema API to create instances of the Task from the Addin (future). Try it out and let me know what you think, -Jayme --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] cl task gone???
> Another solution is by using an task that replaces the > task. It would be used like this: > > > > You would then use the tasks from this assembly as follows: > > > Omitting the prefix attribute just brings the tasks into the default > namespace. The tasks in NAnt.Core would always be in the default namespace. > Consider them "reserved" words. > This makes a hell of alot of sense. I've wondered why the original ant project didn't do something like this. This also brings up the possibility of writing an XML Schema for your task, and validating against it in InitializeTask() since all the elements below the task could (potentially) be prefixed with the same namespace. If you were allowing filesets, there could be a schema for regular NAnt elements (project/target/property/fileset) that you could extend types of, or just include as is. -Jayme --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] cl task gone???
I have a post in NAntContrib's developer list that I'm hoping will solve some of this (for Windows users anyway). I have an MSI task that I would like to use in a target in the NAntContrib script to generate a Windows Installer (.msi) file that will install NAnt, NAntContrib, the VS.NET Addin and SLiNgshoT. The MSI task can set up features (the treeview that shows up in a "custom" install mode) so the user can select/deselect the task libraries he wants. Unfortunately the MSI task is approaching 3k lines of code but I still need to add custom actions and start menu shortcut support to do this. I hope to find the time to get this done sometime later this week. -Jayme - Original Message - From: "Ian MacLean" <[EMAIL PROTECTED]> To: "Gerry Shaw" <[EMAIL PROTECTED]> Cc: "'Jayme Edwards'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, August 19, 2002 7:35 PM Subject: Re: [nant-dev] cl task gone??? > Gerry Shaw wrote: > > >This was intentional and an oversight :) I didn't want those tasks in > >the core tasks but I didn't want to lose them either. There should be a > >NAnt.VisualCppTasks project added with the cl, link and lib task. > > > >I'll add those on Tuesday. In the future I suspect these will live in > >the NAntContrib project. > > > > > I still think that with 90% of Nant users being .Net framework users > that people should only have to download one package to use all the > Framework tools. If we do move them to contrib then we should provide a > build of contrib with the standard NAnt distro. Having an extra task > library that you never use is less of a problem than not being able to > find the task you need. > > Ian > > > >-Original Message- > >From: [EMAIL PROTECTED] > >[mailto:[EMAIL PROTECTED]] On Behalf Of Jayme > >Edwards > >Sent: August 19, 2002 4:38 PM > >To: [EMAIL PROTECTED] > >Subject: [nant-dev] cl task gone??? > > > > > >Hello, > > > >I'm currently updating the build script for the VS.NET Addin for NAnt in > >the NAntContrib project. First off, great job on the refactoring guys - > >it looks really nice. There is one small issue I've ran into however, > >the cl (class linker/C++ compiler) task is no longer available. Since I > >need to compile a > >C++ project into a .dll to provide resources for the Addin, I can't > >C++ build > >this anymore. Is this an oversight, or on purpose? If I'm missing > >something I apologize - otherwise is there something I can do to help > >get this added? > > > >Thanks, > >-Jayme > > > > > > > > > > > -- > "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence." (Edsger Wybe Dijkstra) > > --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] cl task gone???
I'm curious as to why these arent considered "DotNetTasks" (like vbc and csc are) - I'm guessing your thinking was maybe because C++ compilers can generate managed and non-managed code? If so I agree with you, putting them in a separate .dll like you said makes sense. Also, there are at least 9 tasks in NAntContrib right now that are just plain wrappers for Microsoft.NET command-line tools (I still have around 7 left to do) - maybe we can talk in the future about moving these into the NAnt.DotNetTasks.dll as well to give users a full blown NAnt wrapper for the Microsoft.NET SDK when they reference that library. Anyway thanks, I look forward to the availability of the tasks again when you get the VisualCpp stuff going. -Jayme - Original Message - From: "Gerry Shaw" <[EMAIL PROTECTED]> To: "'Jayme Edwards'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, August 19, 2002 7:26 PM Subject: RE: [nant-dev] cl task gone??? > This was intentional and an oversight :) I didn't want those tasks in > the core tasks but I didn't want to lose them either. There should be a > NAnt.VisualCppTasks project added with the cl, link and lib task. > > I'll add those on Tuesday. In the future I suspect these will live in > the NAntContrib project. > > -----Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of Jayme > Edwards > Sent: August 19, 2002 4:38 PM > To: [EMAIL PROTECTED] > Subject: [nant-dev] cl task gone??? > > > Hello, > > I'm currently updating the build script for the VS.NET Addin for NAnt in > the NAntContrib project. First off, great job on the refactoring guys - > it looks really nice. There is one small issue I've ran into however, > the cl (class linker/C++ compiler) task is no longer available. Since I > need to compile a > C++ project into a .dll to provide resources for the Addin, I can't > C++ build > this anymore. Is this an oversight, or on purpose? If I'm missing > something I apologize - otherwise is there something I can do to help > get this added? > > Thanks, > -Jayme > > > > --- > This sf.net email is sponsored by: OSDN - Tired of that same old cell > phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > ___ > Nant-developers mailing list [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/nant-developers > --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] cl task gone???
Hello, I'm currently updating the build script for the VS.NET Addin for NAnt in the NAntContrib project. First off, great job on the refactoring guys - it looks really nice. There is one small issue I've ran into however, the cl (class linker/C++ compiler) task is no longer available. Since I need to compile a C++ project into a .dll to provide resources for the Addin, I can't build this anymore. Is this an oversight, or on purpose? If I'm missing something I apologize - otherwise is there something I can do to help get this added? Thanks, -Jayme --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ___ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Re: Visual Studio.NET Addin initial thoughs
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
[nant-dev] Re: Visual Studio.NET Addin initial thoughs
Just a couple more things, to quicken the process of making a "new" NAnt
script, all we would have to do is add a template to Visual Studio for new
NAnt files (a blank XML file with the project XML element) so someone can
select "Add New Item" from the menus in the IDE to get the dialog that would
display that template. The NAnt Addin already detects new .build files being
added, so it would automatically show up in the tree.
The other things I think that would be cool to add are as you guys were
mentioning in another thread - the ability to take the current VS.NET
project and export it to a .build file that could be looked at with the
Addin and executed. Also Scott had mentioned when I first was contacting him
about contributing this how it would be cool to be able to piggyback an NAnt
script's execution as a pre/post build step in a normal VS project.
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
- Original Message -
From: Jayme Edwards
To: [EMAIL PROTECTED]
Sent: Wednesday, July 17, 2002 2:48 AM
Subject: Visual Studio.NET Addin initial thoughs
Hi guys,
I would just like to let you know where I think the Addin is at, and where I
was trying to get it to. I put it up here specifically so more people could
benefit from it and add features, so I'm all for any improvements you guys
want to make. If you look at the help files that come with it with your
browser in the NAntAddinDocs folder, they explain everything the Addin
currently does.
A summary would be that for any projects open in the IDE that contain .build
files, the addin window shows a tree of these files and allows you to expand
them and view the targets/tasks/properties within. You can select any node
in a project and edit all of its properties using the Properties window in
VS.NET. You can set a target in a project as the "startup target" similar to
the "startup project" in a VS.NET project. You can cut/copy/paste between
multiple NAnt scripts. You can rename properties and targets, and add new
properties/targets/tasks. You can right-click to activate context menus for
any of the common commands on a node. Help is integrated with Visual
Studio.NET and you can also select a node and hit F1 to bring up topics.
They all link to the NAnt help in appropriate locations.
Developers write a class that inherits from NAntTaskNode when they want to
plug a task into the Addin and then configure it in an XML file - and I've
included all the tasks that ship with NAnt releases so far preconfigured.
There is a dialog you can use in the Addin to import custom task nodes
(.dlls someone writes that define the properties window attributes for a
custom task, like the ones in NAntContrib) on the fly, so you can
potentially have nodes with unique icons for as many tasks as someone might
write for NAnt.
When you build a script, the output goes to the VS.NET window - and if an
error occurs you can double-click the line number to go to the line in the
file the error occurred in. This is cool because I had to write zero code to
support it - if your error message is in a .NET exception format the build
window knows how to parse the name of the file and load it up in the IDE.
I left almost all simple properties of the tasks as strings on purpose -
because even many true/false properties of tasks (like "debug") are set
using property replacement (${debug) etc.) in many scripts. Tasks that have
child XML elements like fileset, NDoc documenter elements etc. can be
expanded in the Visual Studio.NET property window to show each member, and
edit each property.
I went in general for simplicity - whats the minimum code a task developer
could write to integrate with the IDE, for the most possible XML data in
their task that they could edit. It seems to work pretty good so far, there
are definately bugs and I'm hoping more of you will become familiar with the
source so you can help out. You can build it using Visual Studio.NET or
NAnt - make sure you read the ReadMeFirst!.htm file that is in the root for
some special directions either way.
Oh by the way, I also wrote that Ant addin for Forte and dontated it to
Netbeans ;). Sun has pretty much taken it over at this point and I am
switched to .NET, so I figured it was time to write one for Microsoft's IDE
instead.
-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
[nant-dev] Visual Studio.NET Addin initial thoughs
Hi guys,
I would just like to let you know where I think the
Addin is at, and where I was trying to get it to. I put it up here specifically
so more people could benefit from it and add features, so I'm all for any
improvements you guys want to make. If you look
at the help files that come with it with your browser in the NAntAddinDocs
folder, they explain everything the Addin currently does.
A summary would be that for any projects open
in the IDE that contain .build files, the addin window shows a tree of these
files and allows you to expand them and view the targets/tasks/properties
within. You can select any node in a project and edit all of its properties
using the Properties window in VS.NET. You can set a target in a project as the
"startup target" similar to the "startup project" in a VS.NET project. You can
cut/copy/paste between multiple NAnt scripts. You can rename properties and
targets, and add new properties/targets/tasks. You can right-click to activate
context menus for any of the common commands on a node. Help is integrated with
Visual Studio.NET and you can also select a node and hit F1 to bring up topics.
They all link to the NAnt help in appropriate locations.
Developers write a class that inherits from
NAntTaskNode when they want to plug a task into the Addin and then configure it
in an XML file - and I've included all the tasks that ship with NAnt
releases so far preconfigured. There is a dialog you can use in the Addin to
import custom task nodes (.dlls someone writes that define the properties window
attributes for a custom task, like the ones in NAntContrib) on the fly, so you
can potentially have nodes with unique icons for as many tasks as someone might
write for NAnt.
When you build a script, the output goes to the
VS.NET window - and if an error occurs you can double-click the line number to
go to the line in the file the error occurred in. This is cool because I had to
write zero code to support it - if your error message is in a .NET exception
format the build window knows how to parse the name of the file and load it up
in the IDE.
I left almost all simple properties of the tasks as
strings on purpose - because even many true/false properties of tasks (like
"debug") are set using property replacement (${debug) etc.) in many scripts.
Tasks that have child XML elements like fileset, NDoc documenter elements etc.
can be expanded in the Visual Studio.NET property window to show each member,
and edit each property.
I went in general for simplicity - whats the
minimum code a task developer could write to integrate with the IDE, for the
most possible XML data in their task that they could edit. It seems to work
pretty good so far, there are definately bugs and I'm hoping more of you will
become familiar with the source so you can help out. You can build it using
Visual Studio.NET or NAnt - make sure you read the ReadMeFirst!.htm file that is
in the root for some special directions either way.
Oh by the way, I also wrote that Ant
addin for Forte and dontated it to Netbeans ;). Sun has pretty much taken it
over at this point and I am switched to .NET, so I figured it was time
to write one for Microsoft's IDE instead.
-Jayme
