Yes, that is indeed what we are doing right now-- mapping the N: drive to a projects directory. I would like to try to avoid using the original name, because for one thing, that requires us to make a large quantity of configuration and .build file changes we would not have to make otherwise.
As I mentioned, we are kind of 'porting' the configuration from a different build machine. I discovered one difference: the old machine actually appears to use a partition labelled N: rather than a drive letter mapped to a directory, as we are currently trying to do. This is leading me to believe that CCNET may not support access to virtual drives/ drive letters mapped to directories? Thanks, Nick On Jan 7, 1:11 am, "Ruben Willems" <[email protected]> wrote: > Hi > > probably that N drive gets mapped when you log on, > maybe some script or so in the startup folder. > so a possible solution is not to use n: > but where that N points to > > c:\builder\something or whatever > > can you post your config file? > maybe I can find something in there > you may strip passwords off course > > with kind regards > Ruben Willems > > On Tue, Jan 6, 2009 at 11:42 PM, n.b. <[email protected]> wrote: > > > Currently I have the service running as the same user which I log into > > windows with. I am still receiving the same error. Would a stack > > trace help? I tried examining the source a bit, but I don't know > > enough to navigate it very quickly. A stack trace follows: > > > ThoughtWorks.CruiseControl.Core.Tasks.BuilderException: Unable to > > execute: N:\bin\NAnt\bin\NAnt.exe -D:BuildEnvironment=DEV > > System.IO.DirectoryNotFoundException: Directory does not exist: N:\bin > > \build\cruise at > > ThoughtWorks.CruiseControl.Core.Util.ProcessInfo.CreateProcess() at > > ThoughtWorks.CruiseControl.Core.Util.ProcessExecutor.RunnableProcess..ctor > > (ProcessInfo processInfo, String projectName) at > > ThoughtWorks.CruiseControl.Core.Util.ProcessExecutor.Execute > > (ProcessInfo processInfo, ProcessMonitor processMonitor) at > > ThoughtWorks.CruiseControl.Core.Tasks.NAntTask.AttemptExecute > > (ProcessInfo info, ProcessMonitor processMonitor) ---> > > System.IO.DirectoryNotFoundException: Directory does not exist: N:\bin > > \build\cruise at > > ThoughtWorks.CruiseControl.Core.Util.ProcessInfo.CreateProcess() at > > ThoughtWorks.CruiseControl.Core.Util.ProcessExecutor.RunnableProcess..ctor > > (ProcessInfo processInfo, String projectName) at > > ThoughtWorks.CruiseControl.Core.Util.ProcessExecutor.Execute > > (ProcessInfo processInfo, ProcessMonitor processMonitor) at > > ThoughtWorks.CruiseControl.Core.Tasks.NAntTask.AttemptExecute > > (ProcessInfo info, ProcessMonitor processMonitor) --- End of inner > > exception stack trace --- at > > ThoughtWorks.CruiseControl.Core.Tasks.NAntTask.AttemptExecute > > (ProcessInfo info, ProcessMonitor processMonitor) at > > ThoughtWorks.CruiseControl.Core.Tasks.NAntTask.Run(IIntegrationResult > > result) at ThoughtWorks.CruiseControl.Core.Project.RunTasks > > (IIntegrationResult result, IList tasksToRun) at > > ThoughtWorks.CruiseControl.Core.Project.Run(IIntegrationResult result) > > at ThoughtWorks.CruiseControl.Core.IntegrationRunner.Build > > (IIntegrationResult result) BaseDirectory: N:\bin\build\cruise, > > Targets: , Executable: N:\bin\NAnt\bin\NAnt.exe, BuildFile: > > STARSService.cc.build > > > The directory listed as not found is visible in explorer. I also find > > it notable that cruise control does not appear to have trouble finding > > the N:\bin\NAnt\bin\ first, since it shares a common ancestor > > directory with N:\bin\build\cruise. I don't believe I have > > configuration file issues since we have used the same configuration > > successfully on another machine. Thanks again, > > > Nick > > > On Jan 6, 1:09 pm, "Ruben Willems" <[email protected]> wrote: > > > Hi > > > > I would set the ccnet service to use the same user as you use when > > logging > > > into windows. > > > maybe this solves the problem. > > > > with kind regards > > > Ruben Willems > > > > On Tue, Jan 6, 2009 at 8:01 PM, n.b. <[email protected]> wrote: > > > > > Thanks very much Craig and Ruben. I should have specified what type > > > > of drive n: is; as you can probably tell from the nature of my > > > > question I am new to CCNET setup. Unfortunately, N: is really just > > > > something my work group uses as an alias for a system directory, to > > > > make automated version control checkouts simpler, I suppose. In other > > > > words, N: is just a drive mapped to a local system directory, not a > > > > network drive. It does seem to be related to running as a service, > > > > though, because if I am reading ccnet.exe output correctly, I am not > > > > encountering the same issue there. > > > > > Thanks, > > > > Nick > > > > > On Jan 6, 1:13 am, "Ruben Willems" <[email protected]> wrote: > > > > > Hi > > > > > > another option is to use UNC paths > > > > > so \\servername\\sharename > > > > > iso N:\ > > > > > > with kind regards > > > > > Ruben Willems > > > > > > On Mon, Jan 5, 2009 at 11:08 PM, n.b. <[email protected]> wrote: > > > > > > > I have run ccnet.exe with my current configuration, and it seems to > > > > > > work fine for the most part, but when I use ccservice, I am > > receiving > > > > > > this error for all of my projects: > > > > > > > ThoughtWorks.CruiseControl.Core.Tasks.BuilderException: > > Unable > > > > to > > > > > > execute: N:\...\NAnt.exe -D:BuildEnvironment=DEV > > > > > > System.IO.DirectoryNotFoundException: Directory does not exist: > > N:\... > > > > > > \cruise > > > > > > > The directory that is indicated not to exist is identified as the > > > > > > baseDirectory in the ccnet.config file. It does indeed exist. > > > > > > > I have also tried running the service both with a local account and > > > > > > with my own domain account (which, as I understand it, is what I > > was > > > > > > running ccnet.exe with). > > > > > > > If anyone has any ideas, or has encountered a similar "directory > > not > > > > > > found issue", please let me know. Thanks, > > > > > > > Nick
