Thanks, that was the problem. I guess the dashboard just enumerates logs in the artifact folder to populate the build history? I had assumed it'd be OK, since the logs contain the name of the project anyway. Putting the project name in the artifact folder explicitly works fine though. Since this causes a broken dashboard, it'd be nice if CCNet warned of clashing artifact folders when it parsed the CCNet.config. Would that be possible?
Re the AppData folder, it's true that different Windows versions name it differently, but you never get it by literal name anyway (use SHGetFolderPath or similar). But I guess if Mono has other problems it's trickier than that. Thanks anyway, Andy On 17 Mar, 07:19, Ruben Willems <[email protected]> wrote: > Hi > > do your projects share artifact folders? > for example > ccnet project A has its artifact folder set to c:\integration\A > ccnet project B has its artifact folder set to c:\integration\A > > that could explain this behaviour > > for the program files folder, > there was a change done to this, but it was not bullet proof > reason : the different windows versions have different derfinitions for > 'appdata' > and also mono had some difficulties with it. > > with kind regards > Ruben Willems > > On Mon, Mar 15, 2010 at 12:55 PM, Andrew McDonald <[email protected] > > > wrote: > > I'm having a strange problem with the CCNet dashboard. Trying to > > configure a 1.5.6804.1 server on Windows Vista Business x64 SP2. > > > If I view the history of a given project, I see the list of build time > > stamps. But clicking on one of these views an entry from a completely > > random project on the server. No project has a history list that > > contains just its own entries. > > > Can anyone help me fix this? I can't see anything obviously wrong with > > the CCNet.config setup. I don't know whether the problem lies with the > > server or dashboard, either. > > > Only one thing was unusual when setting the server up - before trying > > the service, I ran the server as an executable. In this setup it was > > unable to write its 'state' files to the Program Files folder. That's > > to be expected, due to Windows' UAC, as the executable was running > > under my account. After starting it as a service instead, it seemed > > able to write there, but that's when I noticed the dashboard problem. > > Deleting all these state files and letting it continue didn't fix > > things. > > > Side note: apps shouldn't write data to the Program Files folder. Is > > there a change on the cards for this? The server logs, artefacts etc. > > should surely be written to AppData (or equivalent) under Windows...? > > In fact it'd be nice if config files were there too. > > > -- > > Andy McDonald
