NAnt is a free .NET build tool that helps automate the process of building complex software projects. NAnt is similar in concept to build tools like make and Ant. In fact it's very similar to Ant.
( Stolen from Jeffrey McManus' article - [http://www.ondotnet.com/pub/a/dotnet/2003/01/27/nant.html?page=1] )
With Visual Studio .NET, you can easily build and compile .NET projects that contain any number of subprojects -- collections of interdependent web pages, executables, DLL assemblies, and so forth -- with a single menu command. But relying on a single programmer hitting the "compile" button doesn't always work for large and complicated projects. What if you don't care to install VS.NET on every machine you own? Wouldn't it be nice if you had a way to automate the software build process so nobody ever has to hit the compile button? There are many benefits to an automated build process, but to make it happen, you've got to have a build tool.
If you need to distribute your code to many developers who may not have Visual Studio.Net a NAnt build script could be just what you need.
Not yet. Its here.
Build it and place the assembly in the same directory as the main NAnt executable.
Ensure that your assembly is named something like XXXTasks.dll and that it is placed in the same directory as NAnt or in a subdirectory named 'tasks'. Make sure you've got the ~TaskName attribute on your class. Make sure that your ~TaskAttribute attributes are attached to public properties with set methods.
NAnt has a sysinfo task which will inject the set of environment variables and some other system properties into the properties collection under the sys.env namespace. You can then reference them the same way as any other properties. So, for example, you would access the path with ${sys.env.path}. See the sysinfo task help for more info.
Here is a list from some NAnt uses. Use NAnt if you need to :
You should use the build listed on the NAnt home page as the 'stable release' if stability and robustness is what you're after. If you're after the most up-to-date version you are welcome to try one of the nightly builds, although be aware that these are not intended to be release quality. If you encounter something you believe to be a bug with a nightly build, you are encouraged to report it to the NAnt-developers list.
Some tasks that are not in the core NAnt distibution are in a related project called NAntContrib.
NAntContrib is a separate project for extra tasks and extra tools that haven't made it into the core NAnt distribution. The idea is that it's easier to get code added to NAntContrib. It is likely that some tasks will migrate across into NAnt itself as they become more used. The NAntContrib project is located at http://sourceforge.net/projects/nantcontrib.
Build it and place the assembly in the same directory as the main NAnt executable.
A userdoc is automatically created as part of the build process. If the doc in the version you downloaded is out of date, you can always run the userdoc target in NAnt's buildfile.
You can add NAnt to the external tools menu. You can also use the NAnt add-in, which is part of the NAntContrib project.
You have a couple of options:
1. You can use the Slingshot tool
2. You can use Gordons Weakliem's XSL transform to convert .csproj files. See http://radio.weblogs.com/0106046/stories/2002/08/10/supportingVsnetAndNant.html for more information
3. On the BuildFile Builder website (http://dotnet.leadit.be/buildfilebuilder) you can paste a Visual Studio project file and it will generate a NAnt build file.
Alternatly, you could use the
Slingshot is a project for converting Visual Studio .NET solutions to NAnt build files. It is currently part of the NAntContrib project.
Yes. See the Visual C++ tasks and John Lam's docs in NAntUsage.
Yes, there are Visual SourceSafe tasks (see NAntContrib) and hopefully there are CVS tasks in the main distribution. See SourceControl for an overview.
To do this you must explicitly invoke the command processor (cmd.exe) passing your batch file in the command line.
Read the tutorial. Post to the list to see if someone is already working on a similar task. Use the Attrib task as reference, flesh it out, then post it to the developer list for review. Be sure you adhere to our coding guidelines.
Ensure that your assembly is named somthing like XXXTasks.dll and that it is placed in the same directory as NAnt, or in a subdirectory named 'tasks'.
See [http://nant.sourceforge.net/wiki/index.php/Specifying%20.NET%20Framework%20Versions]
Not right now, but hopefully soon. If you have any suggestions in this area, please feel free to post them to the NAnt-users list.
There sure is. Use the include task:
The included file must also be a build file format. Just put standard property definitions in it. somthing like:
The Mono team currently uses an old version of NAnt to build their libraries. The NAnt team has the goal of providing a version of NAnt that is cross-platform (under the Microsoft .NET framework on Windows as well as Mono on Linux), but this needs some work and dedicated testing -- particularly on a Linux machine.
However you execute builds against the mono toolchain on windows right now. Either set the defaultFramework in NAnt.exe.config to a mono-{ver} or set the currentframework property in your buildfile to mono.
See also MonoSupport.
If you use the Visual Studio .NET File Open dialog to open the .build file, there is an arrow to the right of the Open button. Click the arrow and choose *Open With...* You will see a list of options. Choose *HTML/XML Editor*. Click *Set* as default. -ArildFines
You can also do the same thing within the Solution Explorer by right-clicking and choosing Add/Add Existing Item. Add the .build file to your solution. Then right-click the .build file and choose *Open With*. Now follow the previous directions. -ScottPascoe
_Here are more detailed instructions_ (from Duncan Goodwin email on nant-users)
The steps are:
From: Scott Hernandez
Date: Wed, 03 Dec 2003 19:48:55 -0800
In the next nightly build there will be a new target called "deploy-schema"
that will copy the schema file to the vs.net (7.0 and 7.1) schema
directories. That should help a little :)
*Please note* that the targetNamespace is in the form of
="~http://nant.sf.net/schemas/${project.name}-${project.version}.${nant.platform.name}.${nant.settings.currentframework}.xsd"=
which for me became
=~"~http://nant.sf.net/schemas/nant-0.84.win32.net-1.0.xsd";=
on the latest cvs tree. The nightly build will replace the version with the date, I believe.
But the point is that there is _no one namespace; it is always changing_ as
the source code is changing...
_You should now have Intellisense and validation!_
If you're using a task that has a fileset
One way to accomplish this:
You could associate nant.exe with the .build extension. This will build the project's default target, if you double click the .build script in the Windows Explorer. Alternatively you could try the NAntMenu Shell Extension, which populates the .build file's context menu with it's main targets.
They should be now. There was a bug where this was not happening correctly.
Page Information
|
Wiki Information |
Recent PBwiki Blog Posts |