The following JavaScript class enables you to get the expanded coefficients of a binomial raised to a particular power. Pass in the power and it will return an array of coefficients. For example, passing in a power of 6 returns {1, 6, 15, 20, 15, 6, 1}. This is also a row in Pascal's Triangle. It's using the following formula to calculate the coefficients, where n is the the power the binomial is raised to and k is the term position (0 to n).

Here is the class (PascalsTriangle.js):

function PascalsTriangle()
{
    this.GetExpandedBinomialCoefficients = function(power)
    {
        var coefficients = new Array(power);

        for (var index = 0; index <= power; index++)
        {
            coefficients[index] = this.GetExpandedBinomialCoefficient(power, index);
        }

        return coefficients;
    }

    this.GetExpandedBinomialCoefficient = function(power, term)
    {
        return this.GetFactorial(power) / (this.GetFactorial(term) * this.GetFactorial(power - term));
    }

    this.GetFactorial = function(value)
    {
        if (value <= 1)
            return 1;
        else
            return value * this.GetFactorial(value - 1);
    }
}

The class can be used as follows:

var pascalsTriangle = new PascalsTriangle();
var coefficients = pascalsTriangle.GetExpandedBinomialCoefficients(6);
alert(coefficients.join(' '));

This video covers Pascal's Triangle...

...and your 100% sure your xpath is correct. It's probably that there is a namespace defined. All you need to do is define the namespace under the xmlpoke element and prefix your element names with the namespace prefix. Check it:

web.config:

<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
  <appSettings>
    <add key="SomeSetting" value="" />
  </appSettings>
</configuration>

NAnt:

<project name="YadaYadaYada" default="default">
    <target name="default">
        <xmlpoke
             file="D:\Temp\web.config"
             xpath="/ns:configuration/ns:appSettings/ns:add[@key='SomeSetting']/@value"
             value="SomeValue">
                  <namespaces>
                      <namespace prefix="ns" uri="http://schemas.microsoft.com/.NetConfiguration/v2.0" />
                  </namespaces>
         </xmlpoke>
   </target>
</project>

Testing for the existence of a folder with NAnt is pretty simple. The only caveat is that you reference parameters without the ${} qualifier. You can also concatenate strings, building the path dynamically...

<property name="RootPath" value="D:\Temp" />
<property name="RelativePath" value="SomeFolder" />

<target name="default">

   <if test="${directory::exists(RootPath + '\' + SomeFolder)}">
      <echo message="${RootPath}\${SomeFolder} exists!"/>
   </if>

   <if test="${not(directory::exists(RootPath + '\' + SomeFolder))}">
      <echo message="${RootPath}\${SomeFolder} does not exist!"/>
   </if>

</target>

As a side note; if you plan on passing a path into an exec as a parameter remember to quote it with the &quot; HTML entity:

<exec program="${Subversion}">
    <arg value="update &quot;${RootPath}\${SomeFolder}&quot;" />
</exec> 

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.

If you don't appreciate the Automatic Update service automatically rebooting your box after new updates are installed (Who would??), then simply run gpedit.msc to start the Group Policy editor and modify the following policies :

Passing parameters to a NAnt script from CruiseControl.NET is pretty simple. Basically you pass name/value pairs with the -D command line argument in the buildArgs element. Values with spaces need to be wrapped with double quotes. The following CC.NET configuration file illustrates this:

<cruisecontrol>
     <project>
          ...
          <tasks>
               <nant>
                    <executable>C:\Program Files\nant-0.85\bin\NAnt.exe</executable>
                    <baseDirectory>F:\Build\BabelFish2.0\WorkingFolder</baseDirectory>
                    <buildArgs>-D:param1=somevalue -D:param2="some other value"</buildArgs>
                    <nologo>true</nologo>
                    <buildFile>Source/Build/Build.nant</buildFile>
                    <targetList>
                         <target>default</target>
                    </targetList>
                    <buildTimeoutSeconds>2400</buildTimeoutSeconds>
               </nant>
          </tasks>
          ...
     </project>
</cruisecontrol>

The target NAnt script need only reference the properties as follows:

<project name="YadaYadaYada" default="default">
  <target name="default">
    <echo message="Param 1=${param1}, Param 2=${param2}"/>
  </target>
</project>

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.

** UPDATE ** A December 2007 CTP is available, more info here.

Looks like we will have to wait a couple of weeks for WDP support in Visual Studio 2008 as noted by Scott Guthrie:

"Two popular add-ins to Visual Studio are not yet available to download for the final VS 2008 release.  These are the Silverlight 1.1 Tools Alpha for Visual Studio and the Web Deployment Project add-in for Visual Studio. Our hope is to post updates to both of them to work with the final VS 2008 release in the next two weeks."

Got VS2008 Team System up and running... Only issues I ran into were needing to update the .NET Compact Framework 2.0 to SP1 and reinstalling the .NET Framework 3.0 Redist (I had this installed but something got hosed so I had to reinstall it). I ran the beta versions on a VM so I didn't have to deal with issues resulting from uninstalling betas on my dev box. I'm really liking the VM approach for evaluation! 

Rick Strahl has some interesting comments on the VS2008 install here.

I guess this is a known issue with the following exception:

Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'svcutil, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A)
File name: 'svcutil, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' ---> System.Security.SecurityException: Strong name validation failed. (Exception from HRESULT: 0x8013141A)
The Zone of the assembly that failed was:
MyComputer

As a temporary fix you can mark the assembly to be skipped for strong name validation as follows:

sn.exe -Vr svcutil.exe

Evidently the aspnet_compiler.exe does not care about .refresh files (From my tests and what I read on the internets). It would be nice if it did as it would reduce the steps needed to build a WSP (Web Site Project) on a build server. I ended up just manually copying the assemblies into the bin folder before the build as follows in this nant script:

<mkiisdir dirpath="..\BabelFish.ServiceHost.Web" vdirname="BabelFish.ServiceHost.Web" />

<copy todir="..\BabelFish.ServiceHost.Web\bin">
    <fileset basedir="..\BabelFish.Services\bin">
        <include name="*.dll" />
    </fileset>
</copy>

<exec program="C:\WINDOWS\Microsoft.NET\Framework\${framework.version}\aspnet_compiler.exe" useruntimeengine="true">
    <arg value="-p" />
    <arg value="..\BabelFish.ServiceHost.Web" />
    <arg value="-v" />
    <arg value="BabelFish.ServiceHost.Web" />
</exec>

<deliisdir vdirname="BabelFish.ServiceHost.Web" />

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.