MsBuild fails when launched from Go but works in powershell

[TUKET BO]

Hello.
I am trying to compile with msbuild from Go. I built the command that would do the task and tested it in powershell. After that I copied thew same command in a go task but it does not work. Besides the pipeline stage is marked in green which shouldn't be the case since the compilation failed.
Is there anything I have to take into account in order to run msbuild from Go?

[Jason D]

if you are running it via Powershell - I'm no expert but I do know it is a bit touchy when it comes to return codes.  It is likely you are not capturing the return code as you think.

if you are running it directly as a GOCD task here is an example of a manual one that we have, making sure to separate the args:

              <exec command="%MsBuild%" workingdir="Floaters">

<arg>{somesolution}.sln</arg>

<arg>/nologo</arg>

<arg>/verbosity:n</arg>

<arg>/property:Configuration=Release</arg>

<arg>/p:DeployOnBuild=True</arg>

<arg>/p:TargetPlatform=x86</arg>

<runif status="passed" />

</exec>

Also, there is an MSBuild plugin that would make this even cleaner.

[TUKET BO]

Thanks for responding!

Yes, it seems that I am doing it right according to that template.
I tried that plugin too but the same happens.
Also, I tried use a batch script that runs msconfig. Running that script from powershell leads to a successful compilation and launching it from Go throws out a compilation error. Isn't it weird?
I will try to run that script from cmd too.

Tanks for your help.

[TUKET BO]

Sorry, I said "msconfig" but I meant msbuild.

[Aravind SV]

On Wed, Sep 23, 2015 at 4:15 AM, TUKET BO <tuketela...@gmail.com> wrote:

Yes, it seems that I am doing it right according to that template.
I tried that plugin too but the same happens.
Also, I tried use a batch script that runs msconfig. Running that script from powershell leads to a successful compilation and launching it from Go throws out a compilation error. Isn't it weird?

Could it be that the PATH is different, and Powershell is using a 64-bit msbuild and Go is using a different one, or something of that sort? What is the failure? 

[TUKET BO]

The errors are all of this kind:

cl : Command line error D8022: cannot open 'C:\Windows\system32\config\systemprofile\AppData\Local\Temp\tmp27e81590e4e84a3e80a5e88984d64c57.rsp' [D:\Go Agent\pipelines\MainPipeline\server\common\ClientServerCommon.vcxproj]

I don't set any custom PATH.
I will investigate about what you said regarding the posibility of being using another version of msbuild.

Thanks.

[TUKET BO]

Also, I tried to run the script from powershell(32 and 64) and cmd.

[Jeff]

I may be off base here but it looks like the Go Agent is running as the system user and not a normal user which may affect what types of files and PATH settings are available.  I don't run the Go Agent on windows yet so I'm unsure of the implications, but you might try changing the user that the Go Agent is running as.

On Wed, Sep 23, 2015 at 10:25 AM, TUKET BO <tuketela...@gmail.com> wrote:

Also, I tried to run the script from powershell(32 and 64) and cmd.

--
You received this message because you are subscribed to the Google Groups "go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Jeff Vincent
See my LinkedIn profile at:
http://www.linkedin.com/in/rjeffreyvincent

[TUKET BO]

I don't start Go agent nor server by myself. It just launches as a "service" when windows starts. How can I make sure that they are running as administrator?

[TUKET BO]

Hello.

I am still stuck on this.
I come with further information. I tried running the script from the SYSTEM user and works fine. The issue must be on Go launching the script since the Go agent runs as a service under the SYSTEM user.
Does this make sense? Might be an issue in Go?

* In order to get a cmd as SYSTEM I followed this guide: http://blogs.technet.com/b/askds/archive/2008/10/22/getting-a-cmd-prompt-as-system-in-windows-vista-and-windows-server-2008.aspx


Thanks.

[Jason D]

Doubtful it is an issue w/GO.  We have hundreds of pipelines that use various versions of MSBuild to produce artifacts without issue.  Suggestions to debug:

• You can try adding a few tasks to this step in GO to dump environment vars and the like to get a better sense of what they are in the shell that the service is running under.  
• Likely, the service acct permissions are not set as they should be.  Does it have admin access to the "GO Agent" dir?  
• In windows you can also try logging in or doing a "run as" using the service account from a command prompt.  Then, run the msbuild command exactly as GO is doing it.  You should see the same result and may be able to debug it easier when running manually.

[TUKET BO]

Thanks for all your suggestions.

The problem is solved. It was not a Go issue. I am not really sure what fixed the problem but I think that there was garbage in among the build files. If you run over the same problem try to clean up SVN and the VS project.

Thanks.

[Kit Plummer]

I'm seeing the same thing.  Pretty sure it isn't GoCD - the agent.

20:27:38.171   Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23026 for x86
20:27:38.171   Copyright (C) Microsoft Corporation.  All rights reserved.
20:27:38.171   
20:27:38.187 cl : Command line error D8022: cannot open 'C:\Windows\system32\config\systemprofile\AppData\Local\Temp\tmp21bc03ba47b04194bf6a7c45a0f10d32.rsp' [C:\goagent\pipelines\libpng\projects\vstudio\zlib\zlib.vcxproj]

It's weird because running the command as the "Administrator" user on the machine works.  From what I can determine from searching is that it is probably related to the Temp\ subdirectory.  I've read that people are having similar problems with Bamboo.  I've not been able to resolve it yet.