NAnt scripts can get cluttered with configuration values. One way to clean this up is to create properties that are used throughout the script. Although, you could take this a step further and store NAnt script configuration values in an Xml file. I like this approach because it creates a clear separation between the script and modifiable parameters. For example lets say we have an Xml configuration file called Build.config that contains paths:

<?xml version="1.0"?>
<buildConfiguration>
    <paths>
        <path name="SubversionPath" value="C:\Program Files\CollabNet Subversion Server\svn.exe" />
    </paths>
</buildConfiguration>

Our NAnt script could then load these paths into parameters in an "init" target. All other targets could then depend on this "init" target.

I've tried playing with custom configurations (Outside the stock Debug/Release configurations) in the past and found it confusing. So today I tried it again and had much better success. One thing that had me confused is the relationship between Solution level configuration and Project level configuration. What I didn't realize is that they are all completely separate entities... The "Debug" configuration in SolutionA is different from the "Debug" configuration in ProjectA. The "Debug" configuration in ProjectA is different from the "Debug" configuration in ProjectB. They all just happen to have the same name for consistency (Which is where my confusion began; guess I should have read the manual...). Although they are different entities, project level configurations can be mapped to a solution level configuration.

The example below shows a possible configuration. The solution has 2 configurations: "PlanA" and "PlanB". The BLL project have 2 configurations: "Production" and "Staging". The UI project has 2 configurations: "Red" and "Blue". The "PlanA" solution configuration has the BLL project configuration set to "Staging" while the UI project configuration is set to "Red".

So basically the "PlanA" and "PlanB" solution configurations represent a specific combination of project configurations. When you build a solution with a specific solution level configuration it will know what project level configuration to use with each of the individual projects in the solution. "PlanA" would use "Staging" for the BLL and "Red" for the UI.

Another thing that got me is how to add/edit/remove the project level configurations. It's pretty simple; the solution level configuration dropdown (Shown in red above) has a "<New...>" and "<Edit..>" item that enables you to modify solution level configurations. Also each individual project has a configuration dropdown (Shown in blue and green above) that give you the same options for project specific configurations.

Another thing to remember is that when you add a new project, the Debug/Release solution configurations will be automatically re-added. So if you removed these earlier they will have to be removed again.

Oh, and one more thing. Website Projects (WSP) show up as having only one option for configuration and platform with no modification options (Shown in red below). This is because configurations do not apply to a WSP (Since it isnt really a project and does not have a project file). It's a little misleading that there is one item in the list as if its assigned to it. It should just be disabled IMO. In any event it can be ignored. If you want to configure build options for a WSP, create a corresponding Web Deployment Project (WDP). You can then create configurations on the WDP that apply to the the WSP.

I have gotten the following exception a couple of times:

Service 'Translator' has zero application (non-infrastructure) endpoints. This might be because no configuration file was found for your application, or because no service element matching the service name could be found in the configuration file, or because no endpoints were defined in the service element.

There are a number of things that could potentially cause this exception but the one that has gotten me a couple of times is making sure the name attribute of the service element in the .config contains the fully qualified class name. So for example if I have the following service:

namespace BabelFish.ServiceHost.Web
{
    public class Translator : BabelFish.Services.Translator
    {
    }
}

The service name should be as follows (in bold):

In order to configure WCF 3.0 to run under ASP.NET you need to run the installer (ServiceModelReg.exe) in the WFC 3.0 Framework folder (<system drive>\<windows folder>\Microsoft.NET\Framework\v3.0\Windows Communication Foundation) with the /i parameter.

I have been working with the new custom configuration classes in .NET 2.0 and they really make creating custom xml configuration a snap. They are a little quirky to use at first but once you get past the initial learning curve they really make the job a lot easier.

One thing I really wanted to figure out is how to use these new classes to read files other than the default app/web.config. For example if you have one config file that might be shared between exes or if a config file is pulled from a URL. Its actually pretty easy to do.

First create your custom configuration file. It will look exactly the same as a web/app.config file except it will only contain your custom section(s). Create a section handler element identifying the custom section handler and the name of the section. Again, nothing different from doing this in the app/web.config.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
 <configSections>
  <section name="mySettings" type="CustomConfigHandler.MySettingSection, CustomConfigHandler"/>
 </configSections>
 <mySettings>
  <someSetting someAttribute="This is an attribute value from Settings1.config"/>
 </mySettings>
</configuration>

Next create a Configuration object that points to your file by passing in an ExeConfigurationFileMap with the ExeConfigFilename set.

// Create an exe file map containing the path to your config file
ExeConfigurationFileMap FileMap = new ExeConfigurationFileMap();
FileMap.ExeConfigFilename = "MySystem.config";

// Create a configuration object that is tied to your custom config file.
Configuration Config = ConfigurationManager.OpenMappedExeConfiguration(FileMap, ConfigurationUserLevel.None);

// Create the custom config section handler
MySettingSection MySettings = (MySettingSection)Config.GetSection("mySettings");