Had another interesting one today whilst trying to deploy locally during a CI build using MSDeploy, I kept getting the error:

Exception calling "SyncTo" with "4" argument(s): "Connected to the destination computer ("localhost") using the Web Management Service, but could not authorize. Make sure that you are using the correct user name and password, that the site you are connecting to exists, and that the credentials represent a user who has permissions to access the site."

I wanted to use integrated security but the Web Management service just wasn't playing.  So I found that you just need to enable NTLM in the registry:

• Navigate to HKEY_LOCAL_MACHINE\Software\Microsoft\WebManagement\Server
• Create a new DWord key called "WindowsAuthenticationEnabled"
• Set it's value to 1
• Restart the Web Management Service

I'm currently working on using Team City as a continous integration(CI) server rather than TFS as from my experience TFS has never really been a contender as a good CI server, it's far too limited and I might list these out one day.  For the purpose of this post I'm documenting my steps to install TeamCity for production use rather than as a play pen on someones desktop.

Prerequisites

- This presumes that SQL Server is already installed

1. Download and install TeamCity from here:  http://www.jetbrains.com/teamcity/download/
2. Install Team City with the following options:
   
   
   
   
   
   
3. Use AD for security
   
   - Edit C:\TeamCity\.BuildServer\config\main-config.xml
   - Change <login-module> to jetbrains.buildServer.serverSide.impl.auth.NTDomainLoginModule
   - When you navigate to Team City for the first time you'll be prompeted to enter an admin accouint, logging in with a domain account will automatially add that user to the TC admin group
   
   If you find problems trying to login you can try and setup the admins again with http://localhost:8080/setupAdmin.html
4. Enable per project permissions:  Adminstration -> Global Settings -> select "Per-Project permissions"
5. Use SQL Server rather than the internal DB:
   
   - See  http://confluence.jetbrains.net/display/TCD7/Setting+up+an+External+Database#SettingupanExternalDatabase-jtds
   - I used the native SQLJDBC drivers and as per the instructions I created a database.properties file in D:\TeamCity\.BuildServer\config
   - Browse to http://localhost:8080
   - You may get an error saying that some maintenance is required, open the teamcity-server.log and copy the token key at the end of the file and use this to enter the maintenance screen
   - Click "Create Database"
   - After a while the DB will be created, as a success message I received a 404 TomCat message.  
   - Navigating to the Team City home page and running through the admin setup shows that everything is working correctly
6. Setup SMTP Email With Exchange Server
   - Make sure you have the following "roles" installed: Web Server with IIS6 management tools option selected
   - Make sure you have the SMTP feature installed
   - Run the IIS6 Management tools and drill down to the SMTP server
   - On the SMTP server properties -> Delivery Tab -> Advanced -> [enter the smarthost address]
   
   
   
   - Enable relay for the local server:
   
   
7. In Team City -> Administration -> Email Notifier -> [Set SMTP Host to 127.0.0.1]

Notes

• If you need to reconfigure anything afterwards such as changing the TeamCity Data location then you must run C:\TeamCity\Bin\Tomcat7w.exe //ES//TeamCity  which will display a UI where the internal properties can bet set
• Database problems:
  
  SEVERE: The web application [] registered the JDBC driver [org.apache.commons.dbcp.PoolingDriver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.

MSDeploy is really good for deploying websites and syncing up websites but it can be a real pain to configure and get going intially.  The MSDeploy documentation is a bit poor as well and quite often you'll get a very strange error which can be quite cryptic.  Here's a good example that had me stumped for a little while:

Info: Using ID '0204878c-dbb9-4ac8-8d38-1ed9f6f91e0b' for connections to the remote server. Error Code: ERROR_DESTINATION_NOT_REACHABLE More Information: Could not connect to the destination computer ("X.X.X.X"). On the destination computer, make sure that Web Deploy is installed and that the required process ("The Web Management Service") is started.
Error: The remote server returned an error: (404) Not Found.
Error count: 1.

The error message isn't actually too bad in this case, it's saying either the Web Management Service isn't running OR it can't find MSDeploy.  Ok so checklist for this problem:

- Web Management Service (WMSVC) is running on the target server
- Port 8172 is open (checked with Telnet for good measure)
- I can connect to https://servername:8172/msdeploy.axd
- MSDeploy is installed (c:\program files\IIS\MSDeploy\Microsoft Web Deploy V2\msdeploy.exe)

After running through all of this I still received the ERROR_DESTINATION_NOT_REACHABLE message.  So after a while of head scratching I looked at the msdeploy version numbers and noticed that my package was created on the build server using msdeploy version 7.1.1046.1 but on the target servers it was runing the latest version of MSDeploy which at the time of writing is 7.1.1070.1.  Something suspicious perhaps!!  

The Fix

I installed MSDeploy version 7.1.1046.1 on the target servers and bingo no more nasty error messages!  I don't know if this is just a coincidence and I will try and test by upgrading the build server version to the latest MSDepply version but for now this fixed the issue.

Finally decided today that I no longer want to use the DOS command prompt, PowerShell is the way to go for everything!  But when I do use the VS DOS prompt it's normally because I want to use msbuild which means setting the correct envionment path.  A quick Google brings up some samples so I "lifted" one from here and changed it for VS 2010.

In PowerShell locate your profile:

  notepad $profile  (if you get prompted to create the file because you don't have a profile then click yes to create it)

Now here's the contents of Microsoft.PowerShell_profile.ps1:

 pushd 'C:\Program Files\Microsoft Visual Studio 10.0\vc'  
 cmd /c “vcvarsall.bat&set” |  
 foreach {  
  if ($_ -match “=”) {  
   $v = $_.split(“=”); set-item -force -path "ENV:\$($v[0])" -value "$($v[1])"  
  }  
 }  
 popd  
 write-host "`nVisual Studio 2010 PowerShell Prompt" -ForegroundColor Yellow  

Open up PowerShell and all of the VS commands are availble!...Good bye DOS!!

If you need to register and unregister NCover as part of your build process you can easily use the provided NCover.Registration.exe provided by the NCover installation.

Here's a snippet of a build file:

 <BuildRoot>$(MSBuildThisFileDirectory)</BuildRoot>  
 <BuildToolsDir>$(BuildRoot)\BuildTools</BuildToolsDir>  
 <BuildSolutionDir>$(BuildRoot)\Src</BuildSolutionDir>  
   
 <NCoverRootDir>$(BuildToolsdir)\NCover</NCoverRootDir>  
 <NCoverConsoleExe>$(NCoverRootDir)\NCover.Console.exe</NCoverConsoleExe>  
 <NCoverRegistrationExe>$(NCoverRootDir)\NCover.Registration.exe</NCoverRegistrationExe>  
 <NCoverMSBuildTaskAssembly>$(NCoverRootDir)\BuildTaskPlugins\NCover.MSBuildTasks.dll</NCoverMSBuildTaskAssembly>  
   
 <TestMSTestExe>$(VS100COMNTOOLS)\..\IDE\MSTest.exe</TestMSTestExe  
 <TestResultsDir>$(BuildRoot)TestResults</TestResultsDir>  
   
 <UsingTask TaskName="NCover.MSBuildTasks.NCover" AssemblyFile="$(NCoverMSBuildTaskAssembly)"/>  
   
 <Target Name="TestNCoverRegister">  
           <Exec Command="&quot;$(NCoverRegistrationExe)&quot; //license [KEY]"/>       
 </Target>  
        
 <Target Name="TestNCoverUnRegister">  
           <Exec Command="&quot;$(NCoverRegistrationExe)&quot; //deactivate"/>  
 </Target>  
        
 <Target Name="TestUnitsNCover" DependsOnTargets="Prepare">  
           <MsBuild Projects="$(MSBuildProjectFile)" Targets="TestNCoverRegister" Properties="ForceExecute=1"/>       
           <Delete Files="$(TestResultsDir)\UnitTests.trx" />  
           <NCover  
                     BuildId="$(BuildNumber)"  
                     ToolPath="$(NCoverRootDir)"  
                     TestRunnerExe="$(TestMSTestExe)"  
                     TestRunnerArgs="/testcontainer:&quot;$(BuildDir)\MYAPP.UnitTests.dll&quot; /resultsfile:&quot;$(TestResultsDir)\UnitTests.trx&quot; /runconfig:&quot;$(BuildSolutionDir)\LocalTestRun.testrunconfig&quot;"  
                     CoverageFile="$(TestResultsDir)\UnitTestCoverage.nccov"  
           />  
           <MsBuild Projects="$(MSBuildProjectFile)" Targets="TestNCoverUnRegister" Properties="ForceExecute=1"/>  
 </Target>  

Some notes about this build:

• NCover is not installed in the Program Files directory, I like to keep all files required for a solution as part of the source so all of my "tools" are kept in \BuildTools.  This way if a new developer checks out the solution root they don't need to install any additional software (apart from the core things like VS and SQL Server etc)
• You'll notice I'm not using Call task or DependsOnTargets to run the register/unregister targets, I'm using the MsBuild target to call the same build file in order to execute the same MSbuild target twice.  The reason I do this is because I have another integration test target that dopes the same thing as the unit tests but on a different DLL, so I want to be able to call the targets individually or together as part of a commit build 

I'm currently looking at integrating Sonar into our build environment which intially didn't go too well interms of installation so I thought I'd document what I did and what was required for future reference.  In this first part I will show you how to configure Sonar to run with a basic out of the box setup that uses the inbuilt Derby database, localhost web and Core/Squid C# plugins.

PREREQUISITES - VERY IMPORTANT!

1. Download Java JDK, it's works with 1.5+ but I installed 1.7.  
   http://www.oracle.com/technetwork/java/javase/downloads/java-se-jdk-7-download-432154.html

INSTALL SONAR

1. Download Sonar:
   http://sonar.codehaus.org/downloads/
2. Extract to a directory i.e. c:\Sonar
3. Run \bin\windows-x86-32\StartSonar.bat or \bin\windows-x86-64\StartSonar.bat depending on your OS
4. Navigate to http://localhost:9000 to view the default console
   
   At this point Sonar is configured to use the default database.

-----------------------------------------------------------------------------------------------------------------------------------

wrapper  | --> Wrapper Started as Console
wrapper  | Java Service Wrapper Community Edition 3.3.0
wrapper  |   Copyright (C) 1999-2008 Tanuki Software, Inc.  All Rights
Reserved.
wrapper  |     http://wrapper.tanukisoftware.org
wrapper  |
wrapper  | Launching a JVM...
jvm 1    | WrapperManager: Initializing...
jvm 1    | 2009-12-07 16:33:29.166::INFO:  Logging to STDERR via
org.mortbay.log.StdErrLog
jvm 1    | 2009-12-07 16:33:29.211::INFO:  jetty-6.1.17
jvm 1    | 2009-12-07 16:33:29.350::WARN:  Failed startup of context
org.mortbay.jetty.webapp.WebAppContext@635f44d4{/,null}
jvm 1    | java.lang.NullPointerException

fix: I came across this error when I reinstalled Sonar over an existing installation, I had to remove and reinstall from fresh to get around this error

-----------------------------------------------------------------------------------------------------------------------------------

Exception in thread "main" org.sonar.batch.bootstrapper.BootstrapException: org.picocontainer.PicoLifecycleException: PicoLifecycleException: method 'public void org.sonar.batch.index.DefaultIndex.start()', instance 'org.sonar.batch.index.DefaultIndex@39da8a, java.lang.RuntimeException: wrapper at org.sonar.runner.Runner.delegateExecution(Runner.java:155) at org.sonar.runner.Runner.execute(Runner.java:58)at org.sonar.runner.Main.main(Main.java:52)
Caused by: org.picocontainer.PicoLifecycleException: PicoLifecycleException: method 'public void org.sonar.batch.index.DefaultIndex.start()', instance 'org.sonar.batch.index.DefaultIndex@39da8a, java.lang.RuntimeException: wrapper

FIX: sonar-runner can't find a sonar-project.properties file!

In the next part I'll dive into enabling the extra plugins such as Gallio and incorporate NCover reports. 

Whilst trying to get my new build server to work I came across this error:

ThoughtWorks.CruiseControl.Core.CruiseControlException: Source control operation failed: svn: File not found: revision 22, path '/BuildServers/Trunk/Office/Server' . Process command: C:\Program Files\Subversion\bin\svn.exe log svn://localhost/BuildServers/Trunk/Office/Server -r "{2009-07-07T10:53:29Z}:{2009-07-07T10:54:13Z}" --verbose --xml --username build.server --password build --non-interactive --no-auth-cache at ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.Execute(ProcessInfo processInfo) at ThoughtWorks.CruiseControl.Core.Sourcecontrol.Svn.GetModifications(IIntegrationResult from, IIntegrationResult to) at ThoughtWorks.CruiseControl.Core.Sourcecontrol.QuietPeriod.GetModifications(ISourceControl sourceControl, IIntegrationResult lastBuild, IIntegrationResult thisBuild) at ThoughtWorks.CruiseControl.Core.IntegrationRunner.GetModifications(IIntegrationResult from, IIntegrationResult to) at ThoughtWorks.CruiseControl.Core.IntegrationRunner.Integrate(IntegrationRequest request)

After double checking all my settings and paths I realised that the truckUrl property is case sensitive:

<trunkUrl>svn://localhost/BuildServers/trunk/Office/Server</trunkUrl>

Doh!

After installing CruiseControl.Net 1.4.4 I used one of my projects that was working fine in v1.4.2 but when I tried to kick off the build I received the following error:

ThoughtWorks.CruiseControl.Core.CruiseControlException: Unexpected exception caught on server ---> ThoughtWorks.CruiseControl.Core.CruiseControlException: Unable to find Log Publisher for project so can't find log file at ThoughtWorks.CruiseControl.Core.Project.GetLogPublisher() at ThoughtWorks.CruiseControl.Core.Project.GetLogDirectory()

After a brief bit of investigation the only way I could get this working was to add <xmllogger /> as follows:

<publishers>
    <statistics />
    <xmllogger />      
</publishers>

Today I'm installing cc.net v1.4.4, previously I've been using v1.4.2 and I noticed since v1.4.3 the introduction of the CruiseControl.Net Configuration Validation Tool. 

This handy tool does what it says on the tin, just point it at your config file and it'll tell you if your file is valid or not!  Also another useful feature is to look at the processed results, I find this useful to see what defaults cc.net is using and any other tags that I might not have known about.

By default Cruise Control stores the all important ccnet.config file in %ProgramFiles%\CruiseControl.NET\Server,  if you didn’t know CC.Net also monitors this file and will rebuild itself if it detects a change. 

Now the main problem with the default location for ccnet.config is that this is not under source control, so if your build server happens to suddenly “disappear” (this has happened to me) then you’ve lost all of your project configuration.

What I like to do is store ccnet.config in source control and create a project in ccnet.config that monitors this file. 

Benefits:

• CCNet.Config is safe and sound versioned under source control
• Any developer can check out the file and create new projects
• Best of all Cruise Control will detect any changes and magically rebuild itself!  How cool is that!?

Here’s how I do it:

1. Create a new folder structure under source control Build Servers\[SERVER_NAME]\Server
   (By using the build server name you can store multiple server ccnet configs)
2. Checkin your %ProgramFiles%\CruiseControl.NET\Server\ccnet.config file to the Server folder in step 1
   (Copy it to your working folder first!)
3. Modify the following line in %ProgramFiles%\CruiseControl.NET\Server\ccservice.config replacing the path with the location of your working copy on location on the build server.

<add key="ccnet.config" value="C:\Builds\CCNet\Server\ccnet.config"/>

4. Create a new project in ccnet.config like the following:
   

<!-- 

  *********************************************************************************************************************************************

  Cruise Control Config file - Monitors for changes to the main cruise control project config file 

  *********************************************************************************************************************************************

  -->

<project>

  <name>Lon-Build-01 - Config File</name>

  <webURL>http://Lon-Build-01/ccnet/server/local/project/Lon-Build-01+-+Config+File/ViewProjectReport.aspx</webURL>

  <triggers>

    <intervalTrigger seconds="60"/>

  </triggers>

  <workingDirectory>c:\builds\CCNet\Server</workingDirectory>

  <modificationDelaySeconds>0</modificationDelaySeconds>

  <sourcecontrol type="svn">

    <executable>C:\Program Files\SlikSvn\bin\svn.exe</executable>

    <trunkUrl>svn://Lon-Build-01/BuildServers/Trunk/Lon-Build-01/Server</trunkUrl>

    <tagOnSuccess>false</tagOnSuccess>

  </sourcecontrol>

  <publishers>

    <statistics />

  </publishers>

  <externalLinks>

    <externalLink name="IIS Root Web on Localhost" url="http://localhost/" />

  </externalLinks>

</project>

5. Restart the Cruise Control service

Now you have a versioned ccnet.config file and an auto rebuilding build server!

PS Don’t forget to add the new proecjt in CC tray!