Yes, this is a known issue in 1.6. The XML parser was updated to use a more recent one in .NET, but unfortunately it had the side effect of stripping spaces :-(
The original contributor was looking at providing a fix, but I'm not sure whether it has happened or not. Craig -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of erichard Sent: Tuesday, 19 July 2011 2:44 p.m. To: ccnet-user Subject: [ccnet-user] Re: Whitespaces are stripped from the project name when it includes variables in it. Is this a known issue in CC.NET 1.6? My company is hitting this same issue. Things worked fine in CC.NET 1.5 and then when we went to move to CC.NET 1.6, this issue started hitting us. Is there a code fix for this? On Jun 29, 5:22 am, abarinoff <[email protected]> wrote: > Environment: > ------------------- > Microsoft Windows Server 2003 SP2 > CruiseControl.NET-1.6.7981.1 > > Problem Description: > ------------------------------ > When the project name is composed of several variables separated by > spaces those spaces are stripped from the name for some reason. For > example, here is how our project definition looks like: > > <cb:define product="DCA-BHO" browser="IE" version="1.2.0" > buildType="Scheduled" > tagOnSuccess="true" windevNotification="always" > branchLocation="branches/RB-CI_2.3" > buildTime="14:00" labelPrefix="DCA-BHO"/> > > <project name="$(browser) $(product) $(version) $(buildtype)" > queue="ie_queue" category="$(product)" > initialState="Stopped" startupMode="UseInitialState"> > .......... > </project> > > In CC.Net 1.5.0 the project name displayed in Dashboard was "IE DCA- > BHO 1.2.0 Scheduled", but when we tried to migrate to CC.Net 1.6.0 our > projects names broke, they now look like "IEDCA-BHO1.2.0Scheduled" - > no spaces inside. Our builds don't work correctly as the configuration > file and artifacts folders were created in a way to have spaces inside > project names. When we don't use the variables in project name it's > shown with spaces in Dasboard but that's not the approach we would > like to use. > > Is there some way to address that issue via configuration or CC.Net > template files ? Ir should we use another build where this problem is > solved ? If I'm not mistaken there already was such an issue in > earlier versions of CC.Net but it was resolved, so looks like it's > back again.
