ccnet-devel Mailing List for CruiseControl.NET

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:
  http://jira.public.thoughtworks.org/browse/CCNET-129

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: CCNET-129
    Summary: exception during VSS doesn't show up in log
       Type: Bug

     Status: Unassigned
   Priority: Minor

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: CruiseControl .NET
 Components: 
             Builder
   Versions:
             1.0

   Assignee: 
   Reporter: 

    Created: Fri, 30 Jul 2004 3:03 PM
    Updated: Fri, 30 Jul 2004 3:03 PM
Environment: Windows 2000 .NET 1.1

Description:
[project:Error]: Exception: Source control operation failed: Set c:\temp\builds\project as the default folder for project $/?(Y/N)N
A writable copy of c:\temp\builds\project\project.build already exists
. Process command: C:\Program Files\Microsoft Visual Studio\VSS\win32\SS.EXE get $/ -R -Vd7/30/2004;2:51P -Yccnet,ccnet -I-N
----------
ThoughtWorks.CruiseControl.Core.CruiseControlException: Source control operation failed: Set c:\temp\builds\project as the default f
older for project $/?(Y/N)N
A writable copy of c:\temp\builds\project\project.build already exists
. Process command: C:\Program Files\Microsoft Visual Studio\VSS\win32\SS.EXE get $/ -R -Vd7/30/2004;2:51P -Yccnet,ccnet -I-N
   at ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.Execute(ProcessInfo processInfo) in d:\sourceforge\ccnet\pr
oject\core\sourcecontrol\ProcessSourceControl.cs:line 59
   at ThoughtWorks.CruiseControl.Core.Sourcecontrol.Vss.GetSource(IntegrationResult result) in d:\sourceforge\ccnet\project\core\sou
rcecontrol\Vss.cs:line 182
   at ThoughtWorks.CruiseControl.Core.Project.AttemptToRunIntegration(BuildCondition buildCondition, IntegrationResult result) in d:
\sourceforge\ccnet\project\core\Project.cs:line 162
----------




---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.public.thoughtworks.org/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

The following is an  enhancement to the Svn source control class to 
allow the username and password which is used to connect to
svn as a configuration in the config file.

51,56d50
< 		[ReflectorProperty("username", Required = false)]
< 		public string Username;
<
< 		[ReflectorProperty("password", Required = false)]
< 		public string Password;
<
114,130c108
<
< 			System.Text.StringBuilder sb = new System.Text.StringBuilder();
< 			sb.Append(string.Format(HISTORY_COMMAND_FORMAT, 
FormatCommandDate(from), FormatCommandDate(to), _trunkUrl));
< 			
< 			if (this.Username != null && this.Username.Trim().Length > 0)
< 			{
< 				sb.Append(" --username ");
< 				sb.Append(this.Username);
< 			}
<
< 			if (this.Password != null && this.Password.Trim().Length > 0)
< 			{
< 				sb.Append(" --password ");
< 				sb.Append(this.Password);
< 			}
<
< 			return sb.ToString();
---
 > 			return string.Format(HISTORY_COMMAND_FORMAT, 
FormatCommandDate(from), FormatCommandDate(to), _trunkUrl);
135,156c113,114
<
< 			System.Text.StringBuilder sb = new System.Text.StringBuilder();
< 			sb.Append(
< 				string.Format(
< 				TAG_COMMAND_FORMAT, label, _trunkUrl,
< 				this._tagBaseUrl + "/" + label
< 				)
< 			);
<
< 			if (this.Username != null && this.Username.Trim().Length > 0)
< 			{
< 				sb.Append(" --username ");
< 				sb.Append(this.Username);
< 			}
<
< 			if (this.Password != null && this.Password.Trim().Length > 0)
< 			{
< 				sb.Append(" --password ");
< 				sb.Append(this.Password);
< 			}
<
< 			return sb.ToString();
---
 > 			string tagUrl = _tagBaseUrl + "/" + label;
 > 			return string.Format(TAG_COMMAND_FORMAT, label, _trunkUrl, tagUrl);

Be Careful with this.  If you are using Terminal Services or Remote
Desktop and you close the desktop, not logoff, but close, Ctrl-C is sent
to each application.  We ran into this with a poorly written console
application that was wrapped into an NT service.  The console
application was listening for this and doing some clean up, but all of a
sudden our production server would just go loopy.  It turned out that an
operations guy was opening a terminal session to the server and
disconnecting rather than logging off.

-----Original Message-----
From: ccn...@li...
[mailto:ccn...@li...] On Behalf Of
ji...@pu...
Sent: Tuesday, July 27, 2004 2:31 PM
To: ccn...@li...
Subject: [Ccnet-devel] [JIRA] Resolved: (CCNET-120) "port in use"
remoting exception

Message:

   The following issue has been resolved as FIXED.

   Resolver: Owen Rogers
       Date: Tue, 27 Jul 2004 11:30 AM

the remoting channels will now be explicitly unregistered when the ccnet
server shuts down.  this should prevent the port from getting kept open
by cctray.  in order to ensure that the ccnet console shuts down
gracefully, the CTRL-C keystroke is captured and the ccnet server is
properly disposed.
---------------------------------------------------------------------
View the issue:
  http://jira.public.thoughtworks.org/browse/CCNET-120

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: CCNET-120
    Summary: "port in use" remoting exception
       Type: Bug

     Status: Resolved
   Priority: Major
 Resolution: FIXED

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: CruiseControl .NET
   Fix Fors:
             0.7
   Versions:
             0.7

   Assignee: Owen Rogers
   Reporter: Owen Rogers

    Created: Mon, 28 Jun 2004 7:39 AM
    Updated: Tue, 27 Jul 2004 11:30 AM

Description:
a number of people have reported experiencing receiving a "port in use"
remoting exception when restarting ccnet.  the issue is that ccnet does
not properly unregister its remoted objects and close the channels at
shutdown.  normally this is not a problem as the remoting system will
shutdown (closing all channels) after a period of time.  however,
because most people are using cctray, cctray's polling behaviour keeps
remoting from closing the channels.  this is why you receive the "port
in use" method when restarting ccnet.  i'm currently working on a fix
that will make the server clean up properly.  until then, if you are
experiencing this issue, please make sure that you shut down running
instances of cctray before restarting the server.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.public.thoughtworks.org/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=3D4721&alloc_id=3D10040&op=3Dclick
_______________________________________________
Ccnet-devel mailing list
Ccn...@li...
https://lists.sourceforge.net/lists/listinfo/ccnet-devel

The following issue has been updated:

    Updater: Owen Rogers (mailto:or...@th...)
       Date: Tue, 27 Jul 2004 11:39 AM
    Changes:
             timeestimate changed from 0 minutes
             Fix Version changed to 0.7
             Fix Version changed from 1.0
    ---------------------------------------------------------------------
For a full history of the issue, see:

  http://jira.public.thoughtworks.org/browse/CCNET-45?page=history

---------------------------------------------------------------------
View the issue:
  http://jira.public.thoughtworks.org/browse/CCNET-45

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: CCNET-45
    Summary: CCNet console throws an exception when using -help flag
       Type: Bug

     Status: Resolved
   Priority: Minor
 Resolution: FIXED

 Original Estimate: Unknown
 Time Spent: 4 hours
  Remaining: Unknown

    Project: CruiseControl .NET
 Components: 
             Console
   Fix Fors:
             0.7
   Versions:
             0.5

   Assignee: Joachim Chapman
   Reporter: Owen Rogers

    Created: Tue, 13 Apr 2004 9:19 PM
    Updated: Tue, 27 Jul 2004 11:39 AM

Description:
When executing ccnet.exe in a directory where there is no ccnet.config file, the console exe will throw an exception even if the -help flag is used.  The order in which the -help flag is resolved needs to be fixed.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.public.thoughtworks.org/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

Message:

   The following issue has been resolved as FIXED.

   Resolver: Owen Rogers
       Date: Tue, 27 Jul 2004 11:37 AM

uros novak has contributed a patch for this issue.  it is now committed and built into ccnetlive build 0.6.0.326
---------------------------------------------------------------------
View the issue:
  http://jira.public.thoughtworks.org/browse/CCNET-16

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: CCNET-16
    Summary: Implement ModificationFilter SourceControl
       Type: New Feature

     Status: Resolved
   Priority: Minor
 Resolution: FIXED

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: CruiseControl .NET
 Components: 
             Source Control
   Fix Fors:
             0.7
   Versions:
             0.5 (CCNetLive)

   Assignee: Owen Rogers
   Reporter: Owen Rogers

    Created: Thu, 25 Mar 2004 6:06 AM
    Updated: Tue, 27 Jul 2004 11:37 AM

Description:
>> I'd like to be so bold as to suggest a feature that I've been
>> thinking of for awhile.
>>
>> We have a pretty large project with loads of files in CVS.
>> We build with CCNet for .NET but with CC + Ant for Java. The
>> code resides in the same cvs module so any java check in will
>> trigger a client build and vice versa. The build put strain
>> on the machines and takes some time. We've had to reduce the
>> integration time to 1 hour because of it.
>>
>> I'd like to suggest that one can set the path(s) for which
>> a new build should be triggered. Maybe even specify file types.
>> E.g. if files in ...\sharpcode\* has changed, build, otherwise
>> skip the changes. Or, if *.cs;*.csproj files changes trigger
>> a build, otherwise not. Maybe even combination of excludes/includes
>> of files/folders.
>>
>> Anyone else feel that this would be useful?

pip's implementation recommendation:
This came up on the user list. I think a really nice way of implementing 
this would be to write a 'ModificationFilter' class that implements 
'ISourceControl', but decorates an underlying 'real' source control, 
just like the 'MultiSourceControl' class does. It would delegate to the 
underlying ISourceControl to get the full list of modifications, and 
then run filters against the each modification's path.

To start with, it could just do simple single file excludes. I'm 
thinking it may need a way of specifying what the base directory is for 
some source controls (CVS wouldn't need this, but Perforce would since 
it returns full depot paths for modification paths.)

Anyone fancy looking at this? Its a nice self-contained piece and would 
be fairly easy for newbies to the project to work on.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.public.thoughtworks.org/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

Message:

   The following issue has been resolved as FIXED.

   Resolver: Owen Rogers
       Date: Tue, 27 Jul 2004 11:33 AM

this bug was caused for the same reasons as the "port in use" issue: CCNET 120 -- which is now resolved.
---------------------------------------------------------------------
View the issue:
  http://jira.public.thoughtworks.org/browse/CCNET-94

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: CCNET-94
    Summary: CCNet server does not work with HttpChannel
       Type: Bug

     Status: Resolved
   Priority: Minor
 Resolution: FIXED

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: CruiseControl .NET
 Components: 
             Configuration
   Fix Fors:
             0.7
   Versions:
             0.6.1

   Assignee: 
   Reporter: 

    Created: Fri, 21 May 2004 9:25 AM
    Updated: Tue, 27 Jul 2004 11:33 AM

Description:
Mark Miller wrote:

If I change the channel type to http, I get an invalid cast in
VerifyCruiseManagerIsRemoted.  If you have any advice, I'd love to
have those services available.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.public.thoughtworks.org/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

Message:

   The following issue has been resolved as FIXED.

   Resolver: Owen Rogers
       Date: Tue, 27 Jul 2004 11:30 AM

the remoting channels will now be explicitly unregistered when the ccnet server shuts down.  this should prevent the port from getting kept open by cctray.  in order to ensure that the ccnet console shuts down gracefully, the CTRL-C keystroke is captured and the ccnet server is properly disposed.
---------------------------------------------------------------------
View the issue:
  http://jira.public.thoughtworks.org/browse/CCNET-120

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: CCNET-120
    Summary: "port in use" remoting exception
       Type: Bug

     Status: Resolved
   Priority: Major
 Resolution: FIXED

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: CruiseControl .NET
   Fix Fors:
             0.7
   Versions:
             0.7

   Assignee: Owen Rogers
   Reporter: Owen Rogers

    Created: Mon, 28 Jun 2004 7:39 AM
    Updated: Tue, 27 Jul 2004 11:30 AM

Description:
a number of people have reported experiencing receiving a "port in use" remoting exception when restarting ccnet.  the issue is that ccnet does not properly unregister its remoted objects and close the channels at shutdown.  normally this is not a problem as the remoting system will shutdown (closing all channels) after a period of time.  however, because most people are using cctray, cctray's polling behaviour keeps remoting from closing the channels.  this is why you receive the "port in use" method when restarting ccnet.  i'm currently working on a fix that will make the server clean up properly.  until then, if you are experiencing this issue, please make sure that you shut down running instances of cctray before restarting the server.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.public.thoughtworks.org/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:
  http://jira.public.thoughtworks.org/browse/CCNET-128

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: CCNET-128
    Summary: NUnit task should have configurable timeout
       Type: Improvement

     Status: Unassigned
   Priority: Major

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: CruiseControl .NET
 Components: 
             Builder
   Versions:
             0.7

   Assignee: 
   Reporter: 

    Created: Tue, 27 Jul 2004 6:14 AM
    Updated: Tue, 27 Jul 2004 6:14 AM

Description:
The NUnit task should have a configurable timeout property, just like the NAnt Builder.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.public.thoughtworks.org/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

The following comment has been added to this issue:

     Author: Stephane Tombeur
    Created: Tue, 27 Jul 2004 3:07 AM
       Body:
Hi Owen,

I took the 0_6_0_323 build of ccnetlive and tried out the schedule-daily mechanism.

I think there might be a problem with the _integrationTime field. It's defined as a 'System.TimeSpan', but you expect the format to conform to ShortTimePattern. The way the field is used, I thought it would be better to make it of type 'System.DateTime'. In any case, with TimeSpan it doesn't work exactly how you expect it to, being that you fill in a time when integration should occur:
<schedule type="daily" integrationTime="12:00 AM"/> (this doesn't work)

My suggestion:
Either you continue to use a TimeSpan, but then the errormessage should be changed, or you change the property to be of type DateTime.

regards,

Stephane
---------------------------------------------------------------------
View this comment:
  http://jira.public.thoughtworks.org/browse/CCNET-79?page=comments#action_10335

---------------------------------------------------------------------
View the issue:
  http://jira.public.thoughtworks.org/browse/CCNET-79

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: CCNET-79
    Summary: Daily schedule doesn't work right
       Type: Bug

     Status: Resolved
   Priority: Major
 Resolution: FIXED

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: CruiseControl .NET
 Components: 
             Schedule
   Fix Fors:
             0.7
   Versions:
             0.6

   Assignee: 
   Reporter: 

    Created: Fri, 7 May 2004 7:13 AM
    Updated: Tue, 27 Jul 2004 3:07 AM

Description:
The daily schedule doesn't work properly. It doesn't set the next integration to be the next day after an integration ends. After the first integration time passes, it goes into a loop of constantly checking source control for modifications.

It also doesn't allow a forced build. Here is a modified version of DailySchedule.cs and ProjectIntegrator.cs that fixes these two issues. I added the lines delimited with
//**** below.

--- DailySchedule.cs: added 9 lines ---

using Exortech.NetReflector;
using System;
using System.Globalization;
using ThoughtWorks.CruiseControl.Core.Config;
using ThoughtWorks.CruiseControl.Remote;

namespace ThoughtWorks.CruiseControl.Core.Schedules
{
    [ReflectorType("daily")]
    public class DailySchedule : ISchedule
    {
        private TimeSpan _integrationTime;
        private DateTime _nextIntegration;
        //****
        private bool _forceNextBuild = false;
        //****

        [ReflectorProperty("integrationTime")]
        public string IntegrationTime
        {
            get { return _integrationTime.ToString(); }
            set
            {
                try
                {
                    _integrationTime = TimeSpan.Parse(value);
                    SetNextIntegration();
                }
                catch (Exception ex)
                {
                    string msg = "Unable to parse daily schedule integration
time: {0}.  The integration time should be specified in the format: {1}.";
                    throw new ConfigurationException(string.Format(msg,
value, CultureInfo.CurrentCulture.DateTimeFormat.ShortTimePattern), ex);
                }
            }
        }

        private void SetNextIntegration()
        {
            DateTime now = Now;
            _nextIntegration = new DateTime(now.Year, now.Month, now.Day, _integrationTime.Hours, _integrationTime.Minutes, 0, 0);
        }

        public bool ShouldStopIntegration()
        {
            return false;
        }

        public void ForceBuild()
        {
            //****
            _forceNextBuild = true;
            //****
        }

        public void IntegrationCompleted()
        {
            //****
            DateTime now = Now;
            _nextIntegration = new DateTime(now.Year, now.Month, now.Day+1, _integrationTime.Hours, _integrationTime.Minutes, 0, 0);
            //****
        }

        public BuildCondition ShouldRunIntegration()
        {
            //****
            if (_forceNextBuild)
            {
                _forceNextBuild = false;
                return BuildCondition.ForceBuild;
            }
            //****

            if (Now > _nextIntegration)
            {
                return BuildCondition.IfModificationExists;
            }
            return BuildCondition.NoBuild;
        }

        protected virtual DateTime Now
        {
            get { return DateTime.Now; }
        }
    }
}


--- ProjectIntegrator.cs replaced 1 line ---
In ProjectIntegrator.cs you could change ForceBuild() to use reflection to avoid the casting exception at line 86 (error checking could be improved).

public void ForceBuild()
{
    Log.Info("Force Build for project: " + _project.Name);
    Start();

    // ((Schedules.Schedule)_schedule).ForceBuild();     // Replace this
line with the following:
    //****
    _schedule.GetType().InvokeMember("ForceBuild",
System.Reflection.BindingFlags.InvokeMethod, null, _schedule, null);
    //****
}




---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.public.thoughtworks.org/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

I talked to Owen last night, and we decided to add backwards 
compatibility for this change since it was easy to do so. Build 324 and 
onwards will rename your ccnet.state file for you, so you don't need to 
worry.

On a slightly different point, if you *are* using a multi-project server 
and therefore have <state> tags in your config file, you can rename your 
specified state files as described below and then remove your <state> 
tags if you now want to let CCNet handle state file names for you.

Mike

Mike Roberts wrote:

> Hi all,
>
> I have made a change in CCNetLive build 323 that may require you to 
> manually update your system.
>
> If you do not manually specify a 'state' file in your ccnet.config 
> file, build 323 and later will try and use a different file to store 
> the state of the build. If you upgrade from a build before 323 then 
> without any work on your part CCNet will ignore your state file, and 
> start using a new one. This means that your build number will be reset 
> and CCNet will look at all changes in the last 24 hours for the last 
> build.
>
> To work around this, you have the following 2 options:
> - Let CCNet perform its first build and then stop it. Locate the new 
> state file, copy its name, delete it then rename your old state file 
> (ccnet.state) as the new one. Restart CCNet and it will rebuild from 
> your old, but renamed, state file.
> - If this extra build is a problem, you'll need to stop CCNet and 
> rename your state file anyway. The name will reflect the 'Camel Case' 
> name of your project. That means that if your project is called 'my 
> project' then the new state file will be called 'MyProject.state'.
> - If you manually specify the name of your state file in a <state> 
> section, you won't be effected.
>
> This change was made to implement issue CCNet-107. Multi-project 
> instances of CCNet now work without you having to specify the names of 
> your state files.
>
> If you have any questions about this change, please ask.
>
> Mike
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Ccnet-user mailing list
> Ccn...@li...
> https://lists.sourceforge.net/lists/listinfo/ccnet-user

The following comment has been added to this issue:

     Author: 
    Created: Tue, 27 Jul 2004 2:45 AM
       Body:
Breaking change is fixed in build 324 (backwards compatibility now works through renaming old file)
---------------------------------------------------------------------
View this comment:
  http://jira.public.thoughtworks.org/browse/CCNET-107?page=comments#action_10334

---------------------------------------------------------------------
View the issue:
  http://jira.public.thoughtworks.org/browse/CCNET-107

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: CCNET-107
    Summary: Project name should be included in the state file name
       Type: Improvement

     Status: Resolved
   Priority: Minor
 Resolution: FIXED

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: CruiseControl .NET
   Fix Fors:
             0.7
   Versions:
             0.7

   Assignee: 
   Reporter: Owen Rogers

    Created: Sun, 13 Jun 2004 10:25 AM
    Updated: Tue, 27 Jul 2004 2:45 AM

Description:
by default, the state filename should include the project name so that it doesn't cause conflicts when multiple projects are used.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.public.thoughtworks.org/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

The following comment has been added to this issue:

     Author: Stephane Tombeur
    Created: Tue, 27 Jul 2004 1:29 AM
       Body:
I've created an MSBuild plugin. It's basically the same as the NAntBuilder, but with a few tweaks to the arguments. It works for the Visual Studio 2005 Beta 1 release of MSBuild. (v2.0.40607).

It might be necessary to add a <supportedruntime/> tag with the above versionnumber to ccnet.exe.config (not sure about that).

------- start of MSBuilder.cs ---------
using Exortech.NetReflector;
using System;
using System.Threading;
using System.IO;
using ThoughtWorks.CruiseControl.Core.Config;
using ThoughtWorks.CruiseControl.Core.Util;
using ThoughtWorks.CruiseControl.Remote;
using System.Text;

namespace ThoughtWorks.CruiseControl.Core.Builder
{
	[ReflectorType("msbuild")]
	public class MSBuilder : IBuilder
	{
		public const int DEFAULT_BUILD_TIMEOUT = 600;
		public const string DEFAULT_EXECUTABLE = "msbuild.exe";
		public const string DEFAULT_BASEDIRECTORY = ".";
		public const string DEFAULT_LABEL = "NO-LABEL";

		private ProcessExecutor _executor;

		public MSBuilder() : this(new ProcessExecutor()) { }

		public MSBuilder(ProcessExecutor executor)
		{
			_executor = executor;
		}

		[ReflectorProperty("executable", Required = false)] 
		public string Executable = DEFAULT_EXECUTABLE;

		[ReflectorProperty("baseDirectory", Required = false)] 
		public string BaseDirectory = DEFAULT_BASEDIRECTORY;

		[ReflectorProperty("buildFile", Required = false)] 
		public string BuildFile;

		[ReflectorProperty("buildArgs", Required = false)] 
		public string BuildArgs;

		[ReflectorArray("loggerList", Required = false)]
		public string[] Loggers = new string[0];

		[ReflectorArray("targetList", Required = false)] 
		public string[] Targets = new string[0];

		/// <summary>
		/// Gets and sets the maximum number of seconds that the build may take.  If the build process takes longer than
		/// this period, it will be killed.  Specify this value as zero to disable process timeouts.
		/// </summary>
		[ReflectorProperty("buildTimeoutSeconds", Required = false)] 
		public int BuildTimeoutSeconds = DEFAULT_BUILD_TIMEOUT;

		/// <summary>
		/// Runs the integration using MSBuild.  The build number is provided for labelling, build
		/// timeouts are enforced.  The specified targets are used for the specified MSBuild build file.
		/// StdOut from msbuild.exe is redirected and stored.
		/// </summary>
		/// <param name="result">For storing build output.</param>
		public void Run(IntegrationResult result)
		{
			ProcessResult processResult = AttemptExecute(CreateProcessInfo(result));
			result.Output = processResult.StandardOutput;

			if (processResult.TimedOut)
			{
				throw new BuilderException(this, "MSBuild process timed out (after " + BuildTimeoutSeconds + " seconds)");
			}

			if (processResult.ExitCode == 0)
			{
				result.Status = IntegrationStatus.Success;
			}
			else
			{
				result.Status = IntegrationStatus.Failure;
				Log.Info("MSBuild build failed: " + processResult.StandardError);
			}
		}

		private ProcessInfo CreateProcessInfo(IntegrationResult result)
		{
			ProcessInfo info = new ProcessInfo(Executable, CreateArgs(result), BaseDirectory);
			info.TimeOut = BuildTimeoutSeconds*1000;
			return info;
		}

		protected ProcessResult AttemptExecute(ProcessInfo info)
		{
			try
			{
				return _executor.Execute(info);
			}			
			catch (Exception e)
			{
				throw new BuilderException(this, string.Format("Unable to execute: {0}\n{1}", BuildCommand, e), e);
			}
		}

		private string BuildCommand
		{
			get { return string.Format("{0} {1}", Executable, BuildArgs); }
		}

		/// <summary>
		/// Creates the command line arguments to the nant.exe executable. These arguments
		/// specify the build-file name, the targets to build to, 
		/// </summary>
		/// <returns></returns>
		internal string CreateArgs(IntegrationResult result)
		{
			return string.Format("{0} {1} {2} {3} {4}", CreateBuildFileArg(), CreateLoggersArg(), BuildArgs, CreateLabelToApplyArg(result), CreateTargetsArg()).Trim();
		}

		private string CreateBuildFileArg()
		{
			if (StringUtil.IsBlank(BuildFile)) return string.Empty;

			//return "-buildfile:" + BuildFile;
			return BuildFile;
		}

		private string CreateLoggersArg()
		{
			if (Loggers.Length == 0) return string.Empty;

			return string.Join(" /logger:", Loggers);
		}

		private string CreateTargetsArg()
		{
			if (Targets.Length == 0) return string.Empty;

			return "/target:" + string.Join(";", Targets);
		}

		private string CreateLabelToApplyArg(IntegrationResult result)
		{
			string label = StringUtil.IsBlank(result.Label) ? DEFAULT_LABEL : result.Label;
			return "/property:label-to-apply=" + label;
		}

		public bool ShouldRun(IntegrationResult result)
		{
			return result.Working && result.HasModifications();
		}

		public override string ToString()
		{
			return string.Format(@" BaseDirectory: {0}, Targets: {1}, Executable: {2}, BuildFile: {3}", BaseDirectory, CreateTargetsArg(), Executable, BuildFile);
		}
	}
}
----- end of MSBuilder.cs ------

the build node in the config file looks like this:

-----

    <build type="msbuild">
      <executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.40607\MSBuild.exe</executable>
      <baseDirectory>d:\temp\MyProject</baseDirectory>
      <buildArgs>@buildfile.response</buildArgs>
      <buildFile>MyProject.sln</buildFile>
      <targetList>
        <target>All</target>
      </targetList>
      <!-- loggerList is untested, as I don't have any MSBuild loggers yet,
	   see the 3 msbuild articles on MSDN for more info on loggers -->
      <loggerList>
        <logger>SolutionLogger,ACMELogger;file="Build.txt";verbose=true</logger>
      </loggerList>
      <buildTimeoutSeconds>300</buildTimeoutSeconds>
    </build>

-----

All that remains to be done is to create a NAnt-like xml logger for msbuild so that build output can be merged with ccnet build logs.


---------------------------------------------------------------------
View this comment:
  http://jira.public.thoughtworks.org/browse/CCNET-20?page=comments#action_10333

---------------------------------------------------------------------
View the issue:
  http://jira.public.thoughtworks.org/browse/CCNET-20

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: CCNET-20
    Summary: Support for MSBuild
       Type: New Feature

     Status: Open
   Priority: Minor

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: CruiseControl .NET
 Components: 
             Builder
   Fix Fors:
             1.0
   Versions:
             0.5

   Assignee: Owen Rogers
   Reporter: Mike Roberts

    Created: Tue, 30 Mar 2004 12:59 AM
    Updated: Tue, 27 Jul 2004 1:29 AM

Description:
We need an MSBuild Build plugin.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.public.thoughtworks.org/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

Hi all,

I have made a change in CCNetLive build 323 that may require you to 
manually update your system.

If you do not manually specify a 'state' file in your ccnet.config file, 
build 323 and later will try and use a different file to store the state 
of the build. If you upgrade from a build before 323 then without any 
work on your part CCNet will ignore your state file, and start using a 
new one. This means that your build number will be reset and CCNet will 
look at all changes in the last 24 hours for the last build.

To work around this, you have the following 2 options:
- Let CCNet perform its first build and then stop it. Locate the new 
state file, copy its name, delete it then rename your old state file 
(ccnet.state) as the new one. Restart CCNet and it will rebuild from 
your old, but renamed, state file.
- If this extra build is a problem, you'll need to stop CCNet and rename 
your state file anyway. The name will reflect the 'Camel Case' name of 
your project. That means that if your project is called 'my project' 
then the new state file will be called 'MyProject.state'.
- If you manually specify the name of your state file in a <state> 
section, you won't be effected.

This change was made to implement issue CCNet-107. Multi-project 
instances of CCNet now work without you having to specify the names of 
your state files.

If you have any questions about this change, please ask.

Mike

Message:

   The following issue has been resolved as FIXED.

   Resolver: Mike Roberts
       Date: Mon, 26 Jul 2004 9:08 AM

This is fixed in build 323.
NB - This is a *breaking change* for people who don't specify state files explicitly since the state file name now always reflects the project name
---------------------------------------------------------------------
View the issue:
  http://jira.public.thoughtworks.org/browse/CCNET-107

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: CCNET-107
    Summary: Project name should be included in the state file name
       Type: Improvement

     Status: Resolved
   Priority: Minor
 Resolution: FIXED

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: CruiseControl .NET
   Fix Fors:
             0.7
   Versions:
             0.7

   Assignee: 
   Reporter: Owen Rogers

    Created: Sun, 13 Jun 2004 10:25 AM
    Updated: Mon, 26 Jul 2004 9:08 AM

Description:
by default, the state filename should include the project name so that it doesn't cause conflicts when multiple projects are used.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.public.thoughtworks.org/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

The following comment has been added to this issue:

     Author: 
    Created: Fri, 23 Jul 2004 12:38 PM
       Body:
I don't know if it's related or not, but there appear to be thread-safety defects in nant's XmlLogger that only show up on multiprocessor machines.  We've reported this to the nant folks. 
---------------------------------------------------------------------
View this comment:
  http://jira.public.thoughtworks.org/browse/CCNET-105?page=comments#action_10322

---------------------------------------------------------------------
View the issue:
  http://jira.public.thoughtworks.org/browse/CCNET-105

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: CCNET-105
    Summary: Building CCNET fails unit test on multi-processor machine
       Type: Bug

     Status: Open
   Priority: Minor

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: CruiseControl .NET
   Versions:
             0.6
             0.6.1

   Assignee: Owen Rogers
   Reporter: 

    Created: Thu, 10 Jun 2004 11:17 AM
    Updated: Fri, 23 Jul 2004 12:38 PM
Environment: WindowsXP SP1   Dual Xeon 2.4GHz, 1.00GB RAM

Description:
When building the cruise control source (using b.bat), the build fails in the ForceBuild test with a ThreadStateException.  If I set my machine to use only a single processor (through the BIOS), the build works.

The build log follows:

NAnt 0.85 (Build 0.85.1591.0; net-1.1.win32; nightly; 5/10/2004)
Copyright (C) 2001-2004 Gerry Shaw
NAnt Team

Buildfile: file:///G:/DOWNLO~1/tools/CONTIN~1/CC.NET/CRUISE~4.SOU/ccnet.build
Target(s) specified: test 

init:

    [mkdir] Creating directory 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\build'.

compile:

 [solution] Starting solution build.
 [solution] Skipping 'Shared' [build]...
 [solution] Building 'Remote' [build]...
 [solution] Building 'WebService' [build]...
                 [copy] Copying 2 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\WebService\..\..\build\webservice\'.
 [solution] Building 'XMLRPCWebService' [build]...
                 [copy] Copying 2 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\XMLRPCWebService\..\..\build\XMLRPCWebService\'.
                 [copy] Copying 1 file to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\XMLRPCWebService\..\..\build\XMLRPCWebService\'.
 [solution] Building 'WebServiceProxy' [build]...
                 [copy] Copying 2 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\WebServiceProxy\..\..\build\webserviceproxy\'.
 [solution] Building 'CCTray' [build]...
                 [copy] Copying 2 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\CCTray\..\..\build\cctray\'.
                 [copy] Copying 1 file to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\CCTray\..\..\build\cctray\'.
                 [copy] Copying 2 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\CCTray\..\..\build\cctray\'.
                 [copy] Copying 3 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\CCTray\..\..\build\cctray\'.
 [solution] Building 'core' [build]...
                 [copy] Copying 2 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\core\..\..\build\core\'.
                 [copy] Copying 1 file to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\core\..\..\build\core\'.
                 [copy] Copying 1 file to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\core\..\..\build\core\'.
            g:\downloads\tools\ContinuosIntegration\CC.NET\CruiseControl.NET.0.6.1_0_6_0_273.source\project\core\publishers\BuildLogTransformer.cs(54,24): warning CS0618: 'System.Xml.Xsl.XslTransform.Transform(System.Xml.XPath.IXPathNavigable, System.Xml.Xsl.XsltArgumentList)' is obsolete: 'You should pass XmlResolver to Transform() method'
 [solution] Building 'WebDashboard' [build]...
                 [copy] Copying 2 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\WebDashboard\..\..\build\webdashboard\'.
                 [copy] Copying 1 file to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\WebDashboard\..\..\build\webdashboard\'.
                 [copy] Copying 4 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\WebDashboard\..\..\build\webdashboard\'.
 [solution] Building 'web' [build]...
                 [copy] Copying 2 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\web\..\..\build\web\'.
                 [copy] Copying 1 file to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\web\..\..\build\web\'.
                 [copy] Copying 1 file to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\web\..\..\build\web\'.
                 [copy] Copying 2 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\web\..\..\build\web\'.
                 [copy] Copying 3 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\web\..\..\build\web\'.
            g:\downloads\tools\ContinuosIntegration\CC.NET\CruiseControl.NET.0.6.1_0_6_0_273.source\project\web\LogTransformer.cs(34,36): warning CS0618: 'System.Xml.Xsl.XslTransform.Transform(System.Xml.XPath.IXPathNavigable, System.Xml.Xsl.XsltArgumentList)' is obsolete: 'You should pass XmlResolver to Transform() method'
 [solution] Building 'service' [build]...
                 [copy] Copying 2 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\service\..\..\build\service\'.
                 [copy] Copying 1 file to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\service\..\..\build\service\'.
                 [copy] Copying 3 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\service\..\..\build\service\'.
 [solution] Building 'console' [build]...
                 [copy] Copying 6 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\console\..\..\build\server\'.
 [solution] Building 'ControlPanel' [build]...
                 [copy] Copying 2 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\ControlPanel\..\..\build\controlpanel\'.
                 [copy] Copying 2 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\ControlPanel\..\..\build\controlpanel\'.
                 [copy] Copying 1 file to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\ControlPanel\..\..\build\controlpanel\'.
                 [copy] Copying 3 files to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\ControlPanel\..\..\build\controlpanel\'.
     [copy] Copying 1 file to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\build\server\ccnet.exe.config'.
     [copy] Copying 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\console\app.config' to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\build\server\ccnet.exe.config'.
     [copy] Copying 1 file to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\build\service\ccservice.exe.config'.
     [copy] Copying 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\project\service\app.config' to 'G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\build\service\ccservice.exe.config'.

test.unit:

     [exec] G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\tools\nunit\nunit-console.exe ThoughtWorks.CruiseControl.Core.dll /xml:../ThoughtWorks.CruiseControl.Core.dll-results.xml /nologo
            .N.................................................................N......................................................................................................................................................................................F...............................................N.................................................................................................................................
            Tests run: 421, Failures: 1, Not run: 3, Time: 17.2497792 seconds
            
            Failures:
            1) ThoughtWorks.CruiseControl.Core.Test.ProjectIntegratorTest.ForceBuild : System.Threading.ThreadStateException : Thread is running or terminated; it can not restart.
               at System.Threading.Thread.StartInternal(IPrincipal principal, StackCrawlMark& stackMark)
               at System.Threading.Thread.Start()
               at ThoughtWorks.CruiseControl.Core.ProjectIntegrator.Start() in g:\downloads\tools\ContinuosIntegration\CC.NET\CruiseControl.NET.0.6.1_0_6_0_273.source\project\core\ProjectIntegrator.cs:line 74
               at ThoughtWorks.CruiseControl.Core.ProjectIntegrator.ForceBuild() in g:\downloads\tools\ContinuosIntegration\CC.NET\CruiseControl.NET.0.6.1_0_6_0_273.source\project\core\ProjectIntegrator.cs:line 84
               at ThoughtWorks.CruiseControl.Core.Test.ProjectIntegratorTest.ForceBuild() in g:\downloads\tools\ContinuosIntegration\CC.NET\CruiseControl.NET.0.6.1_0_6_0_273.source\project\core\test\ProjectIntegratorTest.cs:line 234
            
            Tests not run:
            1) ThoughtWorks.CruiseControl.Core.Sourcecontrol.Test.StarTeamHistoryParserTest.TestNothing : This is an incomplete test
            2) ThoughtWorks.CruiseControl.Core.Sourcecontrol.Test.VaultTest.HistoryDates : user-specific vault test settings here
            3) ThoughtWorks.CruiseControl.Core.Publishers.Test.NetSendPublisherTest.Send : move to acceptance tests
            

BUILD FAILED

G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\ccnet.build(52,4):
External Program Failed: G:\DOWNLO~1\tools\CONTIN~1\CC.NET\CRUISE~4.SOU\tools\nunit\nunit-console.exe (return code was 1)

Total time: 28.3 seconds.




---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.public.thoughtworks.org/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

The following comment has been added to this issue:

     Author: 
    Created: Fri, 23 Jul 2004 7:26 AM
       Body:
Sorry please remove this issue, it turns out it was a an smtp server issue after all. 
---------------------------------------------------------------------
View this comment:
  http://jira.public.thoughtworks.org/browse/CCNET-124?page=comments#action_10321

---------------------------------------------------------------------
View the issue:
  http://jira.public.thoughtworks.org/browse/CCNET-124

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: CCNET-124
    Summary: email publishers don't work consistently. 
       Type: Bug

     Status: Unassigned
   Priority: Major

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: CruiseControl .NET
 Components: 
             Service
   Versions:
             0.6.1

   Assignee: 
   Reporter: 

    Created: Wed, 21 Jul 2004 9:42 AM
    Updated: Fri, 23 Jul 2004 7:26 AM
Environment: windows 2003 server, latest nightly

Description:
email publisher seems broken.  Works when build fails, but not otherwise.  Here is the exception in the ccnet.log I get when it doesn't send out emails.

7/21/2004 11:52:37 AM: [Integration:Warning]: Exception: Exception thrown by publisher
----------
ThoughtWorks.CruiseControl.Core.CruiseControlException: Exception thrown by publisher ---> ThoughtWorks.CruiseControl.Core.CruiseControlException: EmailPublisher exception: System.Web.HttpException: Could not access 'CDO.Message' object. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Runtime.InteropServices.COMException (0x80040213): The transport failed to connect to the server.

   --- End of inner exception stack trace ---
   at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters)
   at System.RuntimeType.InvokeMember(String name, BindingFlags invokeAttr, Binder binder, Object target, Object[] args, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParameters)
   at System.Web.Mail.LateBoundAccessHelper.CallMethod(Object obj, String methodName, Object[] args)
   --- End of inner exception stack trace ---
   at System.Web.Mail.LateBoundAccessHelper.CallMethod(Object obj, String methodName, Object[] args)
   at System.Web.Mail.CdoSysHelper.Send(MailMessage message)
   at System.Web.Mail.SmtpMail.Send(MailMessage message)
   at ThoughtWorks.CruiseControl.Core.Publishers.EmailGateway.Send(String from, String to, String subject, String messageText) in d:\sourceforge\ccnet\project\core\publishers\EmailGateway.cs:line 22
   at ThoughtWorks.CruiseControl.Core.Publishers.EmailPublisher.SendMessage(String from, String to, String subject, String message) in d:\sourceforge\ccnet\project\core\publishers\EmailPublisher.cs:line 140 ---> System.Web.HttpException: Could not access 'CDO.Message' object. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Runtime.InteropServices.COMException (0x80040213): The transport failed to connect to the server.

   --- End of inner exception stack trace ---
   at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters)
   at System.RuntimeType.InvokeMember(String name, BindingFlags invokeAttr, Binder binder, Object target, Object[] args, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParameters)
   at System.Web.Mail.LateBoundAccessHelper.CallMethod(Object obj, String methodName, Object[] args)
   --- End of inner exception stack trace ---
   at System.Web.Mail.LateBoundAccessHelper.CallMethod(Object obj, String methodName, Object[] args)
   at System.Web.Mail.CdoSysHelper.Send(MailMessage message)
   at System.Web.Mail.SmtpMail.Send(MailMessage message)
   at ThoughtWorks.CruiseControl.Core.Publishers.EmailGateway.Send(String from, String to, String subject, String messageText) in d:\sourceforge\ccnet\project\core\publishers\EmailGateway.cs:line 22
   at ThoughtWorks.CruiseControl.Core.Publishers.EmailPublisher.SendMessage(String from, String to, String subject, String message) in d:\sourceforge\ccnet\project\core\publishers\EmailPublisher.cs:line 140
   --- End of inner exception stack trace ---
   at ThoughtWorks.CruiseControl.Core.Publishers.EmailPublisher.SendMessage(String from, String to, String subject, String message) in d:\sourceforge\ccnet\project\core\publishers\EmailPublisher.cs:line 144
   at ThoughtWorks.CruiseControl.Core.Publishers.EmailPublisher.PublishIntegrationResults(IProject project, IntegrationResult result) in d:\sourceforge\ccnet\project\core\publishers\EmailPublisher.cs:line 127
   at ThoughtWorks.CruiseControl.Core.Publishers.PublisherBase.Project_IntegrationCompleted(Object source, IntegrationCompletedEventArgs e) in d:\sourceforge\ccnet\project\core\publishers\PublisherBase.cs:line 38
   --- End of inner exception stack trace ---
----------


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.public.thoughtworks.org/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

Hi there,

I just wanted to give a 'heads up' to anyone using builds of CCNet from 
CCNetLive. I'm currently in the middle of a major update to the 
'Dashboard' application that will implement the multi-project / 
multi-server / minimal-configuration / combined dashboard and project 
reporter functionality that we've wanted for a while. I've checked some 
changes in, but please bare in mind that before its a bit more complete 
than it currently is that the Dashboard should be considered 'unstable'. 
That said, I will endeavour to keep a working build at all times.

This work has required updates to the server's remote interface so if 
you do use new builds, you may need to update your CCTray application too.

I hope to get this work to a level of stability over the next week or 
so. Once it is, I'll get it up and working on CCNetLive and let you all 
know.

Cheers,

Mike

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:
  http://jira.public.thoughtworks.org/browse/CCNET-127

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: CCNET-127
    Summary: CCTray uses 21 mb memory
       Type: Improvement

     Status: Unassigned
   Priority: Minor

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: CruiseControl .NET
 Components: 
             CCTray
   Versions:
             0.6.1

   Assignee: 
   Reporter: 

    Created: Thu, 22 Jul 2004 7:29 AM
    Updated: Thu, 22 Jul 2004 7:29 AM
Environment: OS: Windows XP

Description:
On my development environment CCTray uses 21 mb of memory.

It connects to a CC server on which four projects are configured.

CCTray is configured to Poll every 60 seconds. Show balloon Notifications and Show exceptions are on.

No of the agents are configured, but all four audio events are enabled.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.public.thoughtworks.org/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:
  http://jira.public.thoughtworks.org/browse/CCNET-126

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: CCNET-126
    Summary: Reasons for build failure not reported when nant called twice
       Type: Bug

     Status: Unassigned
   Priority: Major

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: CruiseControl .NET
   Versions:
             0.6.1

   Assignee: 
   Reporter: Sam Mackrill

    Created: Thu, 22 Jul 2004 5:41 AM
    Updated: Thu, 22 Jul 2004 5:41 AM
Environment: Win2003 Server, nant 0.84, nunit 2.1.4

Description:
My bootstrap (see below) is calling nant twice. If the second call (kit) fails then the build is reported as failed but no reasons are given.

<?xml version="1.0"?>
<project name="LogProcessor-bootstrap" default="go">
  <property name="target" value="test" />
  <property name="backup.file" value="e:\subversion\backups\done\backup\date.txt" />
  <property name="daily.file" value="e:\subversion\Backups\done\dailybuild\date.txt" />
  <property name="daily.flag" value="false" />
  <property name="svn.user" value="cruisecontrol" />
  <property name="svn.pwd" value="sittom" />

  <target name="go" depends="bootstrap, dailycheck, build"/>

  <target name="bootstrap">
    <exec basedir="." program="${svn.executable}" commandline="--username ${svn.user} --password ${svn.pwd} update" />
  </target>
  
  <target name="build">
    <echo message="target=${target}" />
    <nant basedir="." buildfile="LogProcessor.build" target="${target}" inheritall="true" />
    <if propertytrue="daily.flag">
      <nant basedir="." buildfile="LogProcessor.build" target="kit" inheritall="true" />
      <touch file="${daily.file}" />
    </if>
  </target>
  
  <target name="dailycheck">
    <if uptodatefile="${backup.file}" comparefile="${daily.file}">
       <exec basedir="..\LogProcessorAcceptanceTests" program="${svn.executable}" commandline="--username ${svn.user} --password ${svn.pwd} update" />
       <property name="target" value="daily" />
       <property name="daily.flag" value="true" />
    </if>
  </target>
  
</project>



---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.public.thoughtworks.org/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:
  http://jira.public.thoughtworks.org/browse/CCNET-125

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: CCNET-125
    Summary: Multi sourcecontrol causes exception in publisher
       Type: Bug

     Status: Unassigned
   Priority: Major

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: CruiseControl .NET
 Components: 
             Publisher
   Versions:
             0.6.1

   Assignee: 
   Reporter: Sam Mackrill

    Created: Thu, 22 Jul 2004 5:34 AM
    Updated: Thu, 22 Jul 2004 5:34 AM
Environment: Win2003 Server, Nant Build 0.84.1455.0, NUnit 2.1.4

Description:
using this:

    <sourcecontrol type="multi">
      <sourceControls>
        <svn>
          <executable>c:\program files\subversion\bin\svn.exe</executable>
          <trunkUrl>svn://svn.clickstream.net/LogProcessor/trunk</trunkUrl>
        </svn>
        <filesystem>
          <repositoryRoot>e:\subversion\backups\done\backup</repositoryRoot>
        </filesystem>
      </sourceControls>
    </sourcecontrol>

I see the following in the ccnet console output when a file in the backup directory changes:

[LogProcessor:Info]: No modifications detected.
[LogProcessor:Info]: 1 modification detected.
[LogProcessor:Info]: Building
[LogProcessor:Info]: NAnt build failed:
[LogProcessor:Info]: Build complete: Failure
[LogProcessor:Info]: Integration complete: 22/07/2004 13:24:37
[LogProcessor:Warning]: Exception: Exception thrown by publisher
----------
ThoughtWorks.CruiseControl.Core.CruiseControlException: Exception thrown by publ
isher ---> System.ArgumentNullException: Key cannot be null.
Parameter name: key
   at System.Collections.Hashtable.get_Item(Object key)
   at ThoughtWorks.CruiseControl.Core.Publishers.EmailPublisher.GetEmailUser(Str
ing username) in d:\sourceforge\ccnet\project\core\publishers\EmailPublisher.cs:
line 108
   at ThoughtWorks.CruiseControl.Core.Publishers.EmailPublisher.CreateModifiersL
ist(Modification[] modifications) in d:\sourceforge\ccnet\project\core\publisher
s\EmailPublisher.cs:line 193
   at ThoughtWorks.CruiseControl.Core.Publishers.EmailPublisher.CreateRecipientL
ist(IntegrationResult result) in d:\sourceforge\ccnet\project\core\publishers\Em
ailPublisher.cs:line 183
   at ThoughtWorks.CruiseControl.Core.Publishers.EmailPublisher.PublishIntegrati
onResults(IProject project, IntegrationResult result) in d:\sourceforge\ccnet\pr
oject\core\publishers\EmailPublisher.cs:line 121
   at ThoughtWorks.CruiseControl.Core.Publishers.PublisherBase.Project_Integrati
onCompleted(Object source, IntegrationCompletedEventArgs e) in d:\sourceforge\cc
net\project\core\publishers\PublisherBase.cs:line 38
   --- End of inner exception stack trace ---
----------


Here is my publisher config:

    <publishers>
      <xmllogger>
        <logDir>..\web\log\LogProcessor</logDir>
      </xmllogger>
      <email from="bui...@cl..." mailhost="smtp.clickstream.com" includeDetails="TRUE">
       <projectUrl>http://bob/CruiseControl</projectUrl>
       <users>
          <user name="Sam" group="developers" address="si...@cl..."/>
        </users>
        <groups>
          <group name="developers" notification="change"/>
        </groups>
      </email>
    </publishers>
    
If I force the build manually or it triggers from subversion then everything seems fine.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.public.thoughtworks.org/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

The following comment has been added to this issue:

     Author: Sam Mackrill
    Created: Thu, 22 Jul 2004 5:06 AM
       Body:
I have exactly this issue too.
---------------------------------------------------------------------
View this comment:
  http://jira.public.thoughtworks.org/browse/CCNET-122?page=comments#action_10312

---------------------------------------------------------------------
View the issue:
  http://jira.public.thoughtworks.org/browse/CCNET-122

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: CCNET-122
    Summary: Timed out builds repeat indefinitely
       Type: Bug

     Status: Unassigned
   Priority: Major

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: CruiseControl .NET
 Components: 
             Builder
   Versions:
             0.6.1

   Assignee: 
   Reporter: 

    Created: Fri, 16 Jul 2004 8:24 PM
    Updated: Thu, 22 Jul 2004 5:06 AM
Environment: Windows Server 2003, Subversion 1.0.5, NAnt 0.84.1455.0, .NET 1.1

Description:
We have set a build timeout of 20 minutes, and one of the unit tests we've added has caused us to go over the 20 minute time limit. In the process, we uncovered a bug that appears to be new since we upgraded to 0.6.1 (from 0.4.2, I believe).

When a build times out, the system forgets that it's tried to do the build, and continues to do it indefinitely. For example, this is what our log looks like:

[head:Info]: 9 modifications detected.
[head:Info]: Building
[head:Warning]: Process timed out: C:\Working\head\3rdParty\NAnt\nant.exe -buildfile:bootstrap.nant -logger:NAnt.Core.XmlLogger -D:sccs=C:\Subversion\bin\svn.exe -D:label-to-apply=247 go.  Process id: 3948
[head:Warning]: The timed out process has been killed: 3948
[head:Error]: Exception: NAnt process timed out (after 1200 seconds)
----------
ThoughtWorks.CruiseControl.Core.Builder.BuilderException: NAnt process timed out (after 1200 seconds)
   at ThoughtWorks.CruiseControl.Core.Builder.NAntBuilder.Run(IntegrationResult result) in d:\sourceforge\ccnet\project\core\builder\NAntBuilder.cs:line 68
   at ThoughtWorks.CruiseControl.Core.Project.RunBuild(IntegrationResult result) in d:\sourceforge\ccnet\project\core\Project.cs:line 203
   at ThoughtWorks.CruiseControl.Core.Project.AttemptToRunIntegration(BuildCondition buildCondition, IntegrationResult result) in d:\sourceforge\ccnet\project\core\Project.cs:line 163 BaseDirectory: C:\Working\head, Targets: go, Executable: C:\Working\head\3rdParty\NAnt\nant.exe, BuildFile: bootstrap.nant
----------

[head:Info]: 9 modifications detected.
[head:Info]: Building
[head:Warning]: Process timed out: C:\Working\head\3rdParty\NAnt\nant.exe -buildfile:bootstrap.nant -logger:NAnt.Core.XmlLogger -D:sccs=C:\Subversion\bin\svn.exe -D:label-to-apply=247 go.  Process id: 5028
[head:Warning]: The timed out process has been killed: 5028
[head:Error]: Exception: NAnt process timed out (after 1200 seconds)
----------
ThoughtWorks.CruiseControl.Core.Builder.BuilderException: NAnt process timed out (after 1200 seconds)
   at ThoughtWorks.CruiseControl.Core.Builder.NAntBuilder.Run(IntegrationResult result) in d:\sourceforge\ccnet\project\core\builder\NAntBuilder.cs:line 68
   at ThoughtWorks.CruiseControl.Core.Project.RunBuild(IntegrationResult result) in d:\sourceforge\ccnet\project\core\Project.cs:line 203
   at ThoughtWorks.CruiseControl.Core.Project.AttemptToRunIntegration(BuildCondition buildCondition, IntegrationResult result) in d:\sourceforge\ccnet\project\core\Project.cs:line 163 BaseDirectory: C:\Working\head, Targets: go, Executable: C:\Working\head\3rdParty\NAnt\nant.exe, BuildFile: bootstrap.nant
----------

This continues on forever.

The work around is that we have to open up Task Manager and kill the NAnt process during one of these builds. The system then calls this a build failure, and goes on its merry way:

[head:Info]: 9 modifications detected.
[head:Info]: Building
[head:Info]: NAnt build failed:
[head:Info]: Build complete: Failure
[head:Info]: Integration complete: 7/16/2004 8:59:48 PM
[head:Info]: No modifications detected.

Definitely, we've had issues in the past where our builds would time out, and the system handled it gracefully in the past.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.public.thoughtworks.org/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:
  http://jira.public.thoughtworks.org/browse/CCNET-124

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: CCNET-124
    Summary: email publishers don't work consistently. 
       Type: Bug

     Status: Unassigned
   Priority: Major

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: CruiseControl .NET
 Components: 
             Service
   Versions:
             0.6.1

   Assignee: 
   Reporter: 

    Created: Wed, 21 Jul 2004 9:42 AM
    Updated: Wed, 21 Jul 2004 9:42 AM
Environment: windows 2003 server, latest nightly

Description:
email publisher seems broken.  Works when build fails, but not otherwise.  Here is the exception in the ccnet.log I get when it doesn't send out emails.

7/21/2004 11:52:37 AM: [Integration:Warning]: Exception: Exception thrown by publisher
----------
ThoughtWorks.CruiseControl.Core.CruiseControlException: Exception thrown by publisher ---> ThoughtWorks.CruiseControl.Core.CruiseControlException: EmailPublisher exception: System.Web.HttpException: Could not access 'CDO.Message' object. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Runtime.InteropServices.COMException (0x80040213): The transport failed to connect to the server.

   --- End of inner exception stack trace ---
   at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters)
   at System.RuntimeType.InvokeMember(String name, BindingFlags invokeAttr, Binder binder, Object target, Object[] args, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParameters)
   at System.Web.Mail.LateBoundAccessHelper.CallMethod(Object obj, String methodName, Object[] args)
   --- End of inner exception stack trace ---
   at System.Web.Mail.LateBoundAccessHelper.CallMethod(Object obj, String methodName, Object[] args)
   at System.Web.Mail.CdoSysHelper.Send(MailMessage message)
   at System.Web.Mail.SmtpMail.Send(MailMessage message)
   at ThoughtWorks.CruiseControl.Core.Publishers.EmailGateway.Send(String from, String to, String subject, String messageText) in d:\sourceforge\ccnet\project\core\publishers\EmailGateway.cs:line 22
   at ThoughtWorks.CruiseControl.Core.Publishers.EmailPublisher.SendMessage(String from, String to, String subject, String message) in d:\sourceforge\ccnet\project\core\publishers\EmailPublisher.cs:line 140 ---> System.Web.HttpException: Could not access 'CDO.Message' object. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Runtime.InteropServices.COMException (0x80040213): The transport failed to connect to the server.

   --- End of inner exception stack trace ---
   at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters)
   at System.RuntimeType.InvokeMember(String name, BindingFlags invokeAttr, Binder binder, Object target, Object[] args, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParameters)
   at System.Web.Mail.LateBoundAccessHelper.CallMethod(Object obj, String methodName, Object[] args)
   --- End of inner exception stack trace ---
   at System.Web.Mail.LateBoundAccessHelper.CallMethod(Object obj, String methodName, Object[] args)
   at System.Web.Mail.CdoSysHelper.Send(MailMessage message)
   at System.Web.Mail.SmtpMail.Send(MailMessage message)
   at ThoughtWorks.CruiseControl.Core.Publishers.EmailGateway.Send(String from, String to, String subject, String messageText) in d:\sourceforge\ccnet\project\core\publishers\EmailGateway.cs:line 22
   at ThoughtWorks.CruiseControl.Core.Publishers.EmailPublisher.SendMessage(String from, String to, String subject, String message) in d:\sourceforge\ccnet\project\core\publishers\EmailPublisher.cs:line 140
   --- End of inner exception stack trace ---
   at ThoughtWorks.CruiseControl.Core.Publishers.EmailPublisher.SendMessage(String from, String to, String subject, String message) in d:\sourceforge\ccnet\project\core\publishers\EmailPublisher.cs:line 144
   at ThoughtWorks.CruiseControl.Core.Publishers.EmailPublisher.PublishIntegrationResults(IProject project, IntegrationResult result) in d:\sourceforge\ccnet\project\core\publishers\EmailPublisher.cs:line 127
   at ThoughtWorks.CruiseControl.Core.Publishers.PublisherBase.Project_IntegrationCompleted(Object source, IntegrationCompletedEventArgs e) in d:\sourceforge\ccnet\project\core\publishers\PublisherBase.cs:line 38
   --- End of inner exception stack trace ---
----------


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.public.thoughtworks.org/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

This one as well becouse of Datetime formatting:
I'm not sure which is correct, since "30 Aug" is under english and "30 =
VIII" under mine (czech) culture setting.
            Failures:
            1) =
ThoughtWorks.CruiseControl.Web.Test.LogFileListTest.GetLinks :
             String lengths differ.  Expected length=3D34, but was =
length=3D35.
             Strings differ at index 9.

             expected:<"<nobr>30 Aug 2002 16:40 (6)</nobr>">
              but was:<"<nobr>30 VIII 2002 16:40 (6)</nobr>">
             -------------------^

               at =
ThoughtWorks.CruiseControl.Web.Test.LogFileListTest.GetLinks()
 in e:\src\extern\ccnet\project\web\test\LogFileListTest.cs:line 54



Regards,
Martin

Second test-case which is failing for me:

  [Test]
  public void StartProcessRunningCmdExeCallingNonExistentFile()
  {
   ProcessResult result =3D executor.Execute(new ProcessInfo("cmd.exe", =
"/C @zerk.exe foo"));

   AssertProcessExitsWithFailure(result, 1);
   AssertEquals(@"'zerk.exe' is not recognized as an internal or =
external command,
operable program or batch file.", result.StandardError.Trim());
   AssertEquals(string.Empty, result.StandardOutput);
   Assert("process should not have timed out", ! result.TimedOut);
  }

I dont think it is good idea to compare cmd.exe output to fixed string =
since it could vary from system to system or even between windows =
language versions. Moreover win9x/ME do not have cmd.exe at all. What =
about removing this test (it do not test anything important, does it?)


Regards,
Martin

Hello,

Now I'm trying to build ccnet from sources. I builds fine but some tests =
are failing.

First CanCreateHistoryProcess in =
core\sourcecontrol\test\ClearCaseTest.cs. Datetime.Parse is not correct =
under non-english environment. I fixed it to:

   System.IFormatProvider format =3D =
System.Globalization.CultureInfo.InvariantCulture;
   ProcessInfo processInfo =3D _clearCase.CreateHistoryProcessInfo( =
DateTime.Parse(since,format), DateTime.Now );

But even now it fails becouse of bug in the implementation itself IMO =
(assertion error):

            1) =
ThoughtWorks.CruiseControl.Core.Sourcecontrol.Test.ClearCaseTest.CanCreat=
eHistoryProcess :
             String lengths differ.  Expected length=3D138, but was =
length=3D137.
             Strings differ at index 27.

             expected:<"lshist  -r  -nco -since 02-Feb-2002.05:00:00 =
-fmt "%u#~#%Vd#~#...">
              but was:<"lshist  -r  -nco -since 02-II-2002.05:00:00 -fmt =
"%u#~#%Vd#~#%...">
             -------------------------------------^

Looks like invalid datetime formatting again.

Regards,
Martin