Sorry for delay, didn't see this response until now...

Its using the MSBuild Copy task, the default copy that is provied by
msbuild.

I've tried changing the verbosity in the ccnet.exe.config (and the other
service config file) file and the in the ccnet project files for the
individual projects. Also in our targets file where msbuild is called on an
inner project (I know this sounds convoluted, so sorry, but its our internal
build process..:( ).

My attempt at what our hierarchy looks like is this:

1. ccnet.config verbosity setting
2. ccnet project file containing MSBuild blocks which I can pass msbuild
args to (each block contaings a target to call)
3. targets file containing target called from ccnet project file mentioned
in 2. (this contains a call to msbuild passing it the custom vs proj file
that will get built, we have a custom build process after this).

Changing the verbosity of any of these 3 points seems to have had no effect.


I'm looking at trying to use xcopy or robocopy instead  of msbuild copy and
either turn off logging or pipe it to another file.

this is a snippet from our inner targets file. The sourcepath can contain
1000s of files, which match the criteria to be copied.

      <!-- Create a list of files, excluding original and dd paths -->
      <CreateItem Include="$(SourcePath)\**\*.*"

Exclude="$(SourcePath)\**\*.version;$(SourcePath)\Original\**\*.*;$(SourcePath)\dd\**\*.*">
          <Output TaskParameter="Include" ItemName="FirstList"/>
      </CreateItem>

      <!-- Process list of files to only take files which exist in
UserDirectories property -->

      <ItemGroupCreator Source="@(FirstList)" ProcessType="BUILTFILES"
Directories="$(UserDirectories)">
          <Output TaskParameter="DestinationItemGroup" ItemName="FilesToCopy" />
      </ItemGroupCreator>


       <!-- call copy passing in source list and destination location,
skipunchanged files -->
       <Copy SourceFiles="@(FilesToCopy)"
DestinationFiles="@(FilesToCopy->'$(OutputPath)\%(RecursiveDir)%(Filename)%(Extension)')"
SkipUnchangedFiles="true" />



On Sat, Sep 4, 2010 at 10:28 AM, Ruben Willems <[email protected]>wrote:

> Hi
>
>
> with nant and msbuild you can easily change the verbosity level of the copy
> task
>
> what are you using to copy the files?
>
>
>
>
> with kind regards
> Ruben Willems
>
>
>   On Thu, Sep 2, 2010 at 6:24 PM, Michael Guiney <[email protected]
> > wrote:
>
>> Hi,
>>
>> Hoping someone has a workaround for this issue I am having with 
>> cc.netversion 1.5.7256.1. There is an issue logged already which can be found
>> here:
>>
>> http://jira.public.thoughtworks.org/browse/CCNET-1909
>>
>> It seems to be caused by one of the inner build tasks that is part of our
>> build process. This task recursively copies 1000's of file from one location
>> to another. Think ccnet is trying to write the log for this in one piece,
>> i.e. "Copying c:\a\b\c\d\a.txt to D:\a\b\c\d\a.txt" times a 1000+ seems to
>> cause the following error in the event logs:
>>
>> System.OutOfMemoryException: Exception of type
>> 'System.OutOfMemoryException' was thrown.
>>    at System.String.GetStringForStringBuilder(String value, Int32
>> startIndex, Int32 length, Int32 capacity)
>>    at System.Text.StringBuilder.Append(String value)
>>    at System.Text.StringBuilder.AppendLine(String value)
>>    at
>> ThoughtWorks.CruiseControl.Core.Util.ProcessExecutor.RunnableProcess.CollectOutput(String
>> output, StringBuilder collector, EventWaitHandle streamReadComplete, String
>> streamLabel)
>>    at
>> ThoughtWorks.CruiseControl.Core.Util.ProcessExecutor.RunnableProcess.StandardOutputHandler(Object
>> sender, DataReceivedEventArgs outLine)
>>
>> then this error:
>>
>> 2010-09-02 01:02:32,136 [255] ERROR CruiseControl.NET [(null)] - [ProjectA
>> C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe] Exception while
>> collecting standard output
>>
>> I'm taking a look at the task that is copying the files to see if I can
>> change the verbosity or seperate the copy into chunks of files, but it
>> appears to recursively analyze the files in subfolders, so would prefer to
>> avoid that.
>>
>> any suggestions welcome!
>>
>> Mike
>>
>
>

Reply via email to