NAnt itself is a building tool. It does not add any attributes to the application that it creates, unless you instruct it. And this “instruction” is fully customizable and to some extent unique to each application.
When you define a property on the command line, it ends up as a normal NAnt property in your build script (read-only property). Then you decide how to use it to “label” your application.
If your application has an installation package (MSI), it may be advisable to add the MSI property to the package with some assembly information. Or, you might want to add some record to the database or setting in the configuration file, etc.
UPDATED 01/13/2014
Well, here is an example. Suppose your application has a configuration file (based on XML) and contains a parameter called FakeBuild , which affects the behavior of the application, for example. instead of sending real letters to real recipients, it uploads a line to the log file, simulating the moment of sending.
The configuration file may look like this:
<configuration> <settings> ... <setting name="FakeBuild" value="false"> ... </settings> </configuration>
This file is part of your source code, I mean, it lives with the source code in your VCS system. The build script contains instructions for compiling the code, so it also knows the path to the configuration file.
Now the build script checks its own input from the command line and sets the specified 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 above line will only be evaluated if you pass the NAnt build.defines in property. Obviously, you can change the transfer method and therefore check the properties.
We hope that this will facilitate the proposed solution.