Can you give some more context? I am not clear on what was happening when
this error happened. I need a scenario and more of the log than just a
stack trace to be able to help.
On Fri, May 29, 2009 at 12:11 PM, dennisw <dennis.woodr...@rexson.co.uk>wrote:
Sorry about that. I have been using version 0.8 on 2 projects for
around 2 years now without major problems (If it ain't broke don't fix
it applies to these at the moment, although it would be nice to
upgrade sometime). This week I had to get a new build server up and
running and decided to get up to date so I set up my new project's
build server on a VMware box so I could upgrade ncover and other
dependencies without messing up my existing build servers.
I grabbed the latest version from google code and installed it on
Windows 2008 x64 (needed for the project). I found I had to tweak
paths relating to 32-bit apps by appending " (x86)" to the end of $
{environment::get-variable('ProgramFiles')} as in ${environment::get-
variable('ProgramFiles')} (x86)\Microsoft FxCop 1.36".
After I got the dependencies installed and got the server running I
configured ccservice and that went ok too.
My first build (of the buid scripts) seemed ok, but when I added
ccservice and its cofig file I got a build exception on the build
scripts that the svn client was too old for the working copy.
Uninstalled Tortoise 1.6 from the build server and used the downgrade
working copy python script from the svn web site to get the working
copy back to 1.4.
This may be the result of my x86 patching and I realise that CI
Factory is currently targeted at 32 bit build servers, but I really
don't have a choice with this one.
Any more logs or context I can give just let me know. I'm not sure
where to start looking here, whether it is a CCNet IIS problem or a
package problem.
Thanks for your help.
Dennis
May 29, 12:28 pm, Jay Flowers <jay.flow...@gmail.com> wrote:
> Can you give some more context? I am not clear on what was happening when
> this error happened. I need a scenario and more of the log than just a
> stack trace to be able to help.
> On Fri, May 29, 2009 at 12:11 PM, dennisw <dennis.woodr...@rexson.co.uk>wrote:
> > The following error occurs when committing the build scripts.
> > Running on Windows 2008 Server x64.
> > System.Xml.Xsl.XslTransformException: An error occurred while loading
> > document '\SourceModificationReport.xml'. See InnerException for a
> > complete description of the error. --->
> > System.IO.FileNotFoundException: Could not find file 'c:
> > \SourceModificationReport.xml'. File name: 'c:
> > \SourceModificationReport.xml' at System.IO.__Error.WinIOError(Int32
> > errorCode, String maybeFullPath) at System.IO.FileStream.Init(String
> > path, FileMode mode, FileAccess access, Int32 rights, Boolean
> > useRights, FileShare share, Int32 bufferSize, FileOptions options,
> > SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy) at
> > System.IO.FileStream..ctor(String path, FileMode mode, FileAccess
> > access, FileShare share, Int32 bufferSize, FileOptions options, String
> > msgPath, Boolean bFromProxy) at System.IO.FileStream..ctor(String
> > path, FileMode mode, FileAccess access, FileShare share, Int32
> > bufferSize) at System.Xml.XmlDownloadManager.GetStream(Uri uri,
> > ICredentials credentials) at System.Xml.XmlUrlResolver.GetEntity(Uri
> > absoluteUri, String role, Type ofObjectToReturn) at
> > System.Xml.Xsl.Runtime.XmlQueryContext.GetDataSource(String
> > uriRelative, String uriBase) --- End of inner exception stack trace
> > --- at System.Xml.Xsl.Runtime.XmlQueryContext.GetDataSource(String
> > uriRelative, String uriBase) at ChangesDoc(XmlQueryRuntime
> > {urn:schemas-microsoft-com:xslt-debug}runtime) at (XmlQueryRuntime
> > {urn:schemas-microsoft-com:xslt-debug}runtime, XPathNavigator
> > {urn:schemas-microsoft-com:xslt-debug}current) at Root(XmlQueryRuntime
> > {urn:schemas-microsoft-com:xslt-debug}runtime) at
> > System.Xml.Xsl.XmlILCommand.Execute(Object defaultDocument,
> > XmlResolver dataSources, XsltArgumentList argumentList, XmlWriter
> > writer, Boolean closeWriter) at System.Xml.Xsl.XmlILCommand.Execute
> > (IXPathNavigable contextDocument, XmlResolver dataSources,
> > XsltArgumentList argumentList, XmlWriter results) at
> > System.Xml.Xsl.XslCompiledTransform.Transform(IXPathNavigable input,
> > XsltArgumentList arguments, TextWriter results) at
> > ThoughtWorks.CruiseControl.Core.Util.XslTransformer.Transform(String
> > input, String xslFilename, Dictionary`2 xslParams) at
> > ThoughtWorks.CruiseControl.Core.Util.HtmlAwareMultiTransformer.Transform
> > (String input, String[] transformerFileNames, Dictionary`2 xslParams)
> > at
> Sorry about that. I have been using version 0.8 on 2 projects for
> around 2 years now without major problems (If it ain't broke don't fix
> it applies to these at the moment, although it would be nice to
> upgrade sometime). This week I had to get a new build server up and
> running and decided to get up to date so I set up my new project's
> build server on a VMware box so I could upgrade ncover and other
> dependencies without messing up my existing build servers.
> I grabbed the latest version from google code and installed it on
> Windows 2008 x64 (needed for the project). I found I had to tweak
> paths relating to 32-bit apps by appending " (x86)" to the end of $
> {environment::get-variable('ProgramFiles')} as in ${environment::get-
> variable('ProgramFiles')} (x86)\Microsoft FxCop 1.36".
> After I got the dependencies installed and got the server running I
> configured ccservice and that went ok too.
> My first build (of the buid scripts) seemed ok, but when I added
> ccservice and its cofig file I got a build exception on the build
> scripts that the svn client was too old for the working copy.
> Uninstalled Tortoise 1.6 from the build server and used the downgrade
> working copy python script from the svn web site to get the working
> copy back to 1.4.
> Then I forced a build and the build report on the dashboard page at
> This may be the result of my x86 patching and I realise that CI
> Factory is currently targeted at 32 bit build servers, but I really
> don't have a choice with this one.
> Any more logs or context I can give just let me know. I'm not sure
> where to start looking here, whether it is a CCNet IIS problem or a
> package problem.
> Thanks for your help.
> Dennis
> May 29, 12:28 pm, Jay Flowers <jay.flow...@gmail.com> wrote:
> > Can you give some more context? I am not clear on what was happening
> when
> > this error happened. I need a scenario and more of the log than just a
> > stack trace to be able to help.
> > On Fri, May 29, 2009 at 12:11 PM, dennisw <dennis.woodr...@rexson.co.uk
> >wrote:
> > > The following error occurs when committing the build scripts.
> > > Running on Windows 2008 Server x64.
> > > System.Xml.Xsl.XslTransformException: An error occurred while loading
> > > document '\SourceModificationReport.xml'. See InnerException for a
> > > complete description of the error. --->
> > > System.IO.FileNotFoundException: Could not find file 'c:
> > > \SourceModificationReport.xml'. File name: 'c:
> > > \SourceModificationReport.xml' at System.IO.__Error.WinIOError(Int32
> > > errorCode, String maybeFullPath) at System.IO.FileStream.Init(String
> > > path, FileMode mode, FileAccess access, Int32 rights, Boolean
> > > useRights, FileShare share, Int32 bufferSize, FileOptions options,
> > > SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy) at
> > > System.IO.FileStream..ctor(String path, FileMode mode, FileAccess
> > > access, FileShare share, Int32 bufferSize, FileOptions options, String
> > > msgPath, Boolean bFromProxy) at System.IO.FileStream..ctor(String
> > > path, FileMode mode, FileAccess access, FileShare share, Int32
> > > bufferSize) at System.Xml.XmlDownloadManager.GetStream(Uri uri,
> > > ICredentials credentials) at System.Xml.XmlUrlResolver.GetEntity(Uri
> > > absoluteUri, String role, Type ofObjectToReturn) at
> > > System.Xml.Xsl.Runtime.XmlQueryContext.GetDataSource(String
> > > uriRelative, String uriBase) --- End of inner exception stack trace
> > > --- at System.Xml.Xsl.Runtime.XmlQueryContext.GetDataSource(String
> > > uriRelative, String uriBase) at ChangesDoc(XmlQueryRuntime
> > > {urn:schemas-microsoft-com:xslt-debug}runtime) at (XmlQueryRuntime
> > > {urn:schemas-microsoft-com:xslt-debug}runtime, XPathNavigator
> > > {urn:schemas-microsoft-com:xslt-debug}current) at Root(XmlQueryRuntime
> > > {urn:schemas-microsoft-com:xslt-debug}runtime) at
> > > System.Xml.Xsl.XmlILCommand.Execute(Object defaultDocument,
> > > XmlResolver dataSources, XsltArgumentList argumentList, XmlWriter
> > > writer, Boolean closeWriter) at System.Xml.Xsl.XmlILCommand.Execute
> > > (IXPathNavigable contextDocument, XmlResolver dataSources,
> > > XsltArgumentList argumentList, XmlWriter results) at
> > > System.Xml.Xsl.XslCompiledTransform.Transform(IXPathNavigable input,
> > > XsltArgumentList arguments, TextWriter results) at
> > > ThoughtWorks.CruiseControl.Core.Util.XslTransformer.Transform(String
> > > input, String xslFilename, Dictionary`2 xslParams) at
> I still don't understand. Is this happening when you try to open a build
> report?
> On Mon, Jun 1, 2009 at 5:06 AM, dennisw <dennis.woodr...@rexson.co.uk>wrote:
> > Hi Jay,
> > Sorry about that. I have been using version 0.8 on 2 projects for
> > around 2 years now without major problems (If it ain't broke don't fix
> > it applies to these at the moment, although it would be nice to
> > upgrade sometime). This week I had to get a new build server up and
> > running and decided to get up to date so I set up my new project's
> > build server on a VMware box so I could upgrade ncover and other
> > dependencies without messing up my existing build servers.
> > I grabbed the latest version from google code and installed it on
> > Windows 2008 x64 (needed for the project). I found I had to tweak
> > paths relating to 32-bit apps by appending " (x86)" to the end of $
> > {environment::get-variable('ProgramFiles')} as in ${environment::get-
> > variable('ProgramFiles')} (x86)\Microsoft FxCop 1.36".
> > After I got the dependencies installed and got the server running I
> > configured ccservice and that went ok too.
> > My first build (of the buid scripts) seemed ok, but when I added
> > ccservice and its cofig file I got a build exception on the build
> > scripts that the svn client was too old for the working copy.
> > Uninstalled Tortoise 1.6 from the build server and used the downgrade
> > working copy python script from the svn web site to get the working
> > copy back to 1.4.
> > Then I forced a build and the build report on the dashboard page at
> > This may be the result of my x86 patching and I realise that CI
> > Factory is currently targeted at 32 bit build servers, but I really
> > don't have a choice with this one.
> > Any more logs or context I can give just let me know. I'm not sure
> > where to start looking here, whether it is a CCNet IIS problem or a
> > package problem.
> > Thanks for your help.
> > Dennis
> > May 29, 12:28 pm, Jay Flowers <jay.flow...@gmail.com> wrote:
> > > Can you give some more context? I am not clear on what was happening
> > when
> > > this error happened. I need a scenario and more of the log than just a
> > > stack trace to be able to help.
> > > On Fri, May 29, 2009 at 12:11 PM, dennisw <dennis.woodr...@rexson.co.uk
> > >wrote:
> > > > The following error occurs when committing the build scripts.
> > > > Running on Windows 2008 Server x64.
> On Jun 1, 1:18 pm, Jay Flowers <jay.flow...@gmail.com> wrote:
> > I still don't understand. Is this happening when you try to open a build
> > report?
> > On Mon, Jun 1, 2009 at 5:06 AM, dennisw <dennis.woodr...@rexson.co.uk
> >wrote:
> > > Hi Jay,
> > > Sorry about that. I have been using version 0.8 on 2 projects for
> > > around 2 years now without major problems (If it ain't broke don't fix
> > > it applies to these at the moment, although it would be nice to
> > > upgrade sometime). This week I had to get a new build server up and
> > > running and decided to get up to date so I set up my new project's
> > > build server on a VMware box so I could upgrade ncover and other
> > > dependencies without messing up my existing build servers.
> > > I grabbed the latest version from google code and installed it on
> > > Windows 2008 x64 (needed for the project). I found I had to tweak
> > > paths relating to 32-bit apps by appending " (x86)" to the end of $
> > > {environment::get-variable('ProgramFiles')} as in ${environment::get-
> > > variable('ProgramFiles')} (x86)\Microsoft FxCop 1.36".
> > > After I got the dependencies installed and got the server running I
> > > configured ccservice and that went ok too.
> > > My first build (of the buid scripts) seemed ok, but when I added
> > > ccservice and its cofig file I got a build exception on the build
> > > scripts that the svn client was too old for the working copy.
> > > Uninstalled Tortoise 1.6 from the build server and used the downgrade
> > > working copy python script from the svn web site to get the working
> > > copy back to 1.4.
> > > Then I forced a build and the build report on the dashboard page at
> > > This may be the result of my x86 patching and I realise that CI
> > > Factory is currently targeted at 32 bit build servers, but I really
> > > don't have a choice with this one.
> > > Any more logs or context I can give just let me know. I'm not sure
> > > where to start looking here, whether it is a CCNet IIS problem or a
> > > package problem.
> > > Thanks for your help.
> > > Dennis
> > > May 29, 12:28 pm, Jay Flowers <jay.flow...@gmail.com> wrote:
> > > > Can you give some more context? I am not clear on what was happening
> > > when
> > > > this error happened. I need a scenario and more of the log than just
> a
> > > > stack trace to be able to help.
> > > > On Fri, May 29, 2009 at 12:11 PM, dennisw <
> dennis.woodr...@rexson.co.uk
> > > >wrote:
> > > > > The following error occurs when committing the build scripts.
> > > > > Running on Windows 2008 Server x64.
I did run SetupIIS. That ran without error, but there was still no
change.
I then remembered the Scratch.build file and started to build up the
main build line by line. It failed on the very first line:
<call target="SourceModificationReport.PublishOldSource" />
After a bit of digging it seemed I was gettnig and empty
SourceModificationReport.ModificationList
I ended up adding the following to Main.build.xml
<!-- HACK: Added by DW to provide PublishOldSource with a file
list -->
<call
target="SourceModificationReport.CreateModificationList" />
<!-- :HACK -->
<call target="SourceModificationReport.PublishOldSource" />
I am not sure if the list should be already populated by another
target, or if I have found a bug, but that fixed the error and allowed
me to move on.
All of my other issues were related to the dreaded (x86) on the end of
program files.
Thanks for a great product.
Dennis
On Jun 1, 9:04 pm, Jay Flowers <jay.flow...@gmail.com> wrote:
> Did you setup IIS by running the SetupIIS.xml nant script?
> On Mon, Jun 1, 2009 at 8:22 AM, dennisw <dennis.woodr...@rexson.co.uk>wrote:
> > Yes.
> > On Jun 1, 1:18 pm, Jay Flowers <jay.flow...@gmail.com> wrote:
> > > I still don't understand. Is this happening when you try to open a build
> > > report?
> > > On Mon, Jun 1, 2009 at 5:06 AM, dennisw <dennis.woodr...@rexson.co.uk
> > >wrote:
> > > > Hi Jay,
> > > > Sorry about that. I have been using version 0.8 on 2 projects for
> > > > around 2 years now without major problems (If it ain't broke don't fix
> > > > it applies to these at the moment, although it would be nice to
> > > > upgrade sometime). This week I had to get a new build server up and
> > > > running and decided to get up to date so I set up my new project's
> > > > build server on a VMware box so I could upgrade ncover and other
> > > > dependencies without messing up my existing build servers.
> > > > I grabbed the latest version from google code and installed it on
> > > > Windows 2008 x64 (needed for the project). I found I had to tweak
> > > > paths relating to 32-bit apps by appending " (x86)" to the end of $
> > > > {environment::get-variable('ProgramFiles')} as in ${environment::get-
> > > > variable('ProgramFiles')} (x86)\Microsoft FxCop 1.36".
> > > > After I got the dependencies installed and got the server running I
> > > > configured ccservice and that went ok too.
> > > > My first build (of the buid scripts) seemed ok, but when I added
> > > > ccservice and its cofig file I got a build exception on the build
> > > > scripts that the svn client was too old for the working copy.
> > > > Uninstalled Tortoise 1.6 from the build server and used the downgrade
> > > > working copy python script from the svn web site to get the working
> > > > copy back to 1.4.
> > > > Then I forced a build and the build report on the dashboard page at
> > > > This may be the result of my x86 patching and I realise that CI
> > > > Factory is currently targeted at 32 bit build servers, but I really
> > > > don't have a choice with this one.
> > > > Any more logs or context I can give just let me know. I'm not sure
> > > > where to start looking here, whether it is a CCNet IIS problem or a
> > > > package problem.
> > > > Thanks for your help.
> > > > Dennis
> > > > May 29, 12:28 pm, Jay Flowers <jay.flow...@gmail.com> wrote:
> > > > > Can you give some more context? I am not clear on what was happening
> > > > when
> > > > > this error happened. I need a scenario and more of the log than just
> > a
> > > > > stack trace to be able to help.
> > > > > On Fri, May 29, 2009 at 12:11 PM, dennisw <
> > dennis.woodr...@rexson.co.uk
> > > > >wrote:
> > > > > > The following error occurs when committing the build scripts.
> > > > > > Running on Windows 2008 Server x64.
|
