Will Smith so kindly pointed out that the target file for web application projects is not installed by the .NET 3.5 redist (Along with msbuild). To fix this you can copy over the target file from a machine with VS2008 installed to the same folder on build server. The target file can be found under <ProgramFiles>\MSBuild\Microsoft\VisualStudio\v9.0\WebApplications.

I mistakenly grabbed the latest WiX installer from here but the latest builds for version 3 are here under the weekly releases. There was an issue with the 3.0.2925 release with referencing the NETFRAMEWORK35 property in the WixNetFxExtension. This is fixed in later releases.

BTW, WiX rocks! Visual Studio 2008 integration is very nice. If you are looking for an alternative to the stock VS setup project and need more control over the MSI, I'd check it out.

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

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):

I have seen a lot of posts on this and they all say something along the lines of 'simply go and set the path to the base vhd...'. Well, being a Virtual Server user, it wasn't as obvious to do as it is with VPC.  To do it in VS you need to...

1) Copy the VS 2008 VM to a folder in your VS2005 path and add it.

2) Copy the base VM (Which can be downloaded here) to a folder in your VS2005 path.

3) Under "Virtual Disks" click "Inspect", select the VS2008 vhd and click "Inspect".

4) The "Parent virtual hard disk(s)" property will show a link indicating that the parent drive could not be found. Click this link to set the location of the drive.

5) Once selected, click "Update parent path", start the VM and Login with administrator/P2ssw0rd.