This is a general property of environment variables. It will affect both ccservice.exe and ccnet.exe. Wikipedia even (sort of) describes it: http://en.wikipedia.org/wiki/Environment_variables
There is a relatively easy way to test this with a command prompt. Open up a command prompt and run 'set'. It should list your current environment variables. Add a new one in the System's properties sheet (right click My Computer -> properties -> Advanced tab -> Environment Variables). Run 'set' in the command prompt again -- the new property should not appear. But if you start a new command prompt and run 'set', the new variable will appear in the new window. CC.Net's environment variables are determined by the same behaviour. This is what makes me slightly nervous about proposals to have "build-scoped" variables passed around in environment variables. It is a way of using them slightly at odds with their "natural" way of working. Dave Cameron CruiseControl.NET - http://ccnet.thoughtworks.com On Thu, Jan 29, 2009 at 6:17 PM, Craig & Sammi Sutherland <[email protected]> wrote: > Hi again, > > > > I did some more research on this – it turns out the path (and all > environment variables) are read only once, at system start-up. So if the > path is changed while the system is running the services will not detect any > changes to it (at least in Win2003 see > http://support.microsoft.com/kb/887693). > > > > The other possibility I saw is the service is running under a different > account, and therefore has different environment variables. Therefore > changing the path under your login wouldn't affect CC.Net running under a > service. > > > > So, either way this is something that happens because CC.Net is running as a > service – not anything that was done especially for CC.Net. > > > > Hope this helps, > > > > > > Craig > > > > From: [email protected] [mailto:[email protected]] On > Behalf Of Craig & Sammi Sutherland > Sent: Thursday, 29 January 2009 10:00 p.m. > To: [email protected] > Subject: [ccnet-user] Re: Query for the developers > > > > Hi Shaun, > > > > I ran a quick test for you - yes CC.Net does cache the system path. I'm not > sure why, or where, but it may be something to do with the way the service > runs. > > > > I also tested modifying the configuration (i.e. ccnet.config), which is > cached, but this didn't update the path that CC.Net uses. So this means the > path isn't stored with the configuration. > > > > You'd probably need to restart at least the service, but I didn't test that. > > > > > > Craig > > > > > > From: [email protected] [mailto:[email protected]] On > Behalf Of Ruben Willems > Sent: Thursday, 29 January 2009 9:41 p.m. > To: [email protected] > Subject: [ccnet-user] Re: Query for the developers > > > > Hi > > > I did not know this, but rebooting the pc was a bit overkill I think > if you touched the ccnet.config file (add a space or so at the end) CCNet > would consider this a change, and reload everything. > > I'll check if I can find a cache somewhere ;-) > > with kind regards > Ruben Willems > > On Thu, Jan 29, 2009 at 9:13 AM, CinnamonDonkey > <[email protected]> wrote: > > Hi, > > This is probably one for Ruben or some other clever developer type. > > Does CCNET cache the system path in code? I only ask because our > nightly build failed and the only thing that had changed was the > python installation. > > The error was that is could not execute Python. > > Due to a particular Python API that I need to use I had to role back > from version 2.6 of Python to version 2.5. This was a simple process > and should not have affected CCNET as it was not being referred to by > absolute path in anyway (It's on the system path so there is no > need). > > > The system path was updated to reflect the changes and I know Python > had installed correctly because I was scripting all day yestarday so I > know it was working from the command line. > > Rebooting the machine, hence shutting down and restarting CCNET. Seems > to have fixed the problem. CCNET can now access python. > > This leads me to think that CCNET is caching the system path so when > changes are made it is unaware. > > Regards, > Shaun > >
