I have created a task (VersionTask) that reads the AssemblyVersion
attribute from the AssemblyInfo.cs file.  It handles all of the valid
version number formats:
1
1.2
1.2.*
1.2.3
1.2.3.*
1.2.3.4

It can set a nant property (Project.Properties) to any prefix of this
version number, that is it can set the property to "1", "1.2", "1.2.3",
or "1.2.3.4".  Therefore it can replace the script task in NAnt.build
which reads the version number.

It can also optionally increment any portion of the version number
(major.minor.build.revision).  I use it to increment the revision number
every time I build, and increment the build number on nightly builds.

It's set up as a base class, a utilty class, the VersionTask class
itself, and a BuildnumTask that I use to manage version numbers in c++
.h files.  It's in 4 files because that's the coding convention
specified on
http://sourceforge.net/docman/display_doc.php?docid=6080&group_id=31650.
I doubt anyone else will find the BuildNum task very useful, but I could
probably generalize it to make it better.

So, here's my question.  Assuming other people find this task useful,
should I include it in nant?  If so, where?  I've currently got it set
up to load dynamically by putting it in a VersionTasks.dll file which I
move into the bin directory after a build.   I'd just as soon leave it
like that, but it makes sense to me to change NAnt.build to use
VersionTask.  If so, it seems that it should go into the nant core.  If
I do that, I probably won't put my BuildnumTask into the core, I'll
leave that as a dynamically loaded task.  But I will need to put the
base class and the utility class into the core.  If it's not thought to
be generally useful I'll put it under Extras.

Any thoughts?

Eric.

_______________________________________________
Nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers

Reply via email to