NAnt on its own is a build tool. It doesn't add any attributes to the application it builds, unless you instruct it to. And this "instruction" is totally custom and to some extent unique for each application.
When you define a property in the command-line, it ends up as a normal NAnt property in your build script (a read-only property, to be precise). Then it is up to you how to use it to "label" your application.
If your app has an installation package (MSI), it might make sense to add an MSI property to the package with some build info. Or, you might want to add some database record, or a setting in the config file, etc.
UPDATED 13.01.2014
Okay, here it an example. Let's assume your application has configuration file (XML-based) and it contains a setting called FakeBuild
, which influences the behavior of the application, e.g. instead of sending real emails to real recipients it dumps a line to the log file simulating the sending moment.
The configuration file might look like this:
<configuration>
<settings>
...
<setting name="FakeBuild" value="false">
...
</settings>
</configuration>
This file is a part of your source code, I mean, it lives with the source code in your VCS system. Build script contains instructions to compile the code, hence it knows the path to the configuration file as well.
Now, the build script checks its own input from the command-line, and sets the mentioned setting to true
or false
respectively. For instance:
<xmlpoke file="${path.to.config}" value="true" xpath="configuration/settings/setting[@name='FakeBuild']/@value" if="${property::exists('build.defines')}"/>
The line above will evaluate only if you pass the NAnt property build.defines
in. Obviously, you can modify the way you pass and therefore check for properties.
Hope this sheds more light to the proposed solution.