Until now, I've always used the XsdTask (from NantContrib) to generate my
typed datasets from xml schemas. I've found that using this this task has
several disadvantages:
* You can't use filesets to generate datasets from a collections of xml schemas.
Since my entire build environment is based on generic buildfiles which are included in each project-specific buildfile, this is a major pain.
Agreed. Adding fileset support to the existing xsd task would be possible. Unfortunately xsd.exe only takes a single input file paramater so a fileset solution would have to spawn it multiple times.
* The xsdtask does not check if the sources are up to date; it always generates the datasets. Actually, this issue is more related to xsd.exe itself.
You can implement an uptodate check yourself. See the resgentask and the NeedsCompiling method
* It's pretty slow, since it's based on the execution of an external executable.how much slower is this ? Bear in mind that all the compiler tasks are external executables.
To fix this, I've created my own TypedDataSetGenerator task, which is based on the TypedDataSetGenerator found in the System.Data assembly. While it overlaps somewhat with the XsdTask (which can do more than generate datasets), it does solve the above
metioned issues.
The downside with linking to System.Data directly ( as opposed to wrapping an exe ) is that when you run a build nant will link to the System.Data it was built with and not necessarily the one that the build is targetting. What I mean by this is that you can tell nant which framework you are going to use when you run a build and then the framework tools for that version will be used ie from C:\WINDOWS\Microsoft.NET\Framework\v1.0.3705 or C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322.
however binding directly to the classes means that you could be targetting the 1.1 framework but using the system.Data from 1.0 possibly resulting in output that differs from what the framework tools would provide.
If there's interest, I could post this task to the list. I'm not sure whether it should be placed in Nant.DotNetTasks or NantContrib, though.
Ideally this should be one task I think - located in Nant.DotNetTasks. Having multiple tasks with overlapping functionality only leads to user confusion.
I've also started work on making filesets referentialable(?), which means that one could
use a ref attribute to denote another fileset marked with an ID attribute.
Sounds great. Looking forward to seeing it.
Ian
Expect patches next week.
Best,
Arjen
-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
