I finally upgraded from using 0.85 ~ May 21 or so to 0.85 Nov 15, 2004
version. For those of you thinking about making this move, here I some
of the things I ran into in my build files:
(1) string::substring no longer takes -1 length to represent the end of
the string.
(2) Properties that you pass into nant are now read only. I had some
<property> settings at the beginning of the build file that wrote in
default values. I added some unless... tags to them. The error message
was cryptic, saying that "{0} cannot be overwritten". Sounds like a bug
in the error reporting, too. (String.Format??)
(3) Some names of attributes of some of my custom tasks were not entered
correctly. The older version of nant did not catch this, but the new
version does. I was able to correct attribute names.
(4) Some C++ projects that I had been building could no longer find some
of my files -- namely I construct a CommonAssemblyAttributes.cpp file,
but it is in another folder. I had an <includefolder> tag, but that
doesn't seem to do the job anymore. I copied the file into the current
build folder, and the problem is solved.
(5) All by project build files link specifically to nunit as a literal,
i.e.
<csc ...>
<references>
...
<include name="C:\program files\nunit
v2.1\bin\nunit.framework.dll"/>
...
</references>
</csc>
Now <Nunit2> only likes NUnit2.2, and complains about using v 2.1. The
problem is that if I want to build earlier versions of my program (using
the previous .build files) with the newest NANT, generate the <config>
file for each of my projects to redirect nunit! Yuck. I'm thinking
about making a property in my build file called build.nantversion. If
build.nantversion is <2.2, I can generate the config file on the fly for
each test. I can also generate a property called build.nantdll that
contains something like "C:\Program Files\nunit
v2.1\bin\nunit.framework.dll" or such to pass to the individual projects
to use in the references sections.
(6) I used assembly::get-name to get the assembly name from a string.
This used to return a string, but now returns something else. I have
changed that to assemblyname::get-assembly-name.
(7) Is there a way to determine if a dll is a managed assembly? Not all
my dlls are managed. In the past, running <nunit2> on an unmanaged
assembly would cause it to fail. The expedient solution was to keep a
list of which dlls where unmanaged and skip the unit tests on them.
(8) I had to rebuild my custom tasks (all related to TeamCoherence
source control)
Stephen Lewis
Envisioneering LLC - Medical Products
St. Louis, MO 63114
(314) 429-7367 x112
-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
Nant-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-users
