Jenkins pipeline and MSBuild 2017

1,111 views
Skip to first unread message

Reza Etezal

unread,
Sep 1, 2017, 6:59:30 PM9/1/17
to Jenkins Users
I have been struggling to get msbuild to work properly from the Jenkins pipeline. I am trying to build a number of solution files with a lot of interdependencies. There are about 15 solution files in total, and several dozen csproj files.

The first five or so build fine, but the sixth one fails with the following error:

C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(748,5): error : The OutputPath property is not set for project '<project_name_here>'.  Please check to make sure that you have specified a valid combination of Configuration and Platform for this project.  Configuration='Debug'  Platform='Any CPU'.  You may be seeing this message because you are trying to build a project without a solution file, and have specified a non-default Configuration or Platform that doesn't exist for this project. 

This is happening to a csproj that is marked as a dependency in a solution. So, SLN -> csproj(1) -> csproj(2) and when I try to build the solution, csproj(1) tries to build csproj(2) and fails to do so. This doesn't happen any time other than when initiated from Jenkins pipeline.

The thing that has had me pulling all of my hair out over the last week is that the exact same commands, issued from the command line, fail to reproduce the error, with the solution being compiled properly. Furthermore, when using the MSBUILD plugin for Jenkins and using a Freestyle project to run the builds, I also do not see any errors and the build finishes successfully. Here are a few of the things I have tried over the last week:

- using both 'bat' and 'powershell' to execute the commands
- installing, uninstalling, re-installing in different order VS2017 and BuildTools2017
- changing the Jenkins service account (this is a non-domain-joined Windows Server 2016 machine) from localsystem to a local admin user, back to localsystem with ability interact with desktop, back to local admin user
- re-configuring the node and re-installing the service (JWS installed as Windows service, JNLP4 transport)
- when using bat, doing a "call %VSTOOLS_PATH%\vsdevcmd.bat" (and the msbuildcmd.bat). they load the paths (as seen by an ECHO %PATH%)
- hard-coding all the paths from above to user, system, both PATH variable

As mentioned, I created a Freestyle project and used the BAT task to nuget restore, and the MSBUILD plugin task to run msbuild. This works fine, and seems to compile all of the things with no breaking errors. From there, I saw that the there is a CHCP 1252 command being issues before the msbuild command, which changes, for whatever reason, the encoding to Western Europe. I tried that in the bat section of my pipeline script, and can see that the paging changes to 1252, but no joy on the build. I have tried starting the Jenkins jar using different encodings as well (by adding the java option in the jenkins-slave.xml file), but that only gives my gibberish in the log file.

I have effectively pulled every hair out of my head, and there is a sizeable dent in both my desk and my skull, and I can't get this google-forsaken solution to build.

Is there anyone who can shed some light on where I'm going so horribly wrong?

Ivo Bellin Salarin

unread,
Sep 2, 2017, 2:31:04 AM9/2/17
to Jenkins Users

You describe the problem as a Jenkins problem. Fine. But the level of logs you have doesn't tell you anything, because that's not the tools which is failing. Don't take me wrong, but you should get the msbuild logs at a debug level, and find out what's different between the executions.

The initial problem is a missing variable. The only solution you have is to find out why the variable isn't being set in this particular environment.

I know how a pain in the neck is inspecting msbuild debug level logs, but it's the only deterministic solution you have to get your hair back. 😉

So, add /v:diag to your msbuild logs.

And, BTW, the chcp command was probably there to influence the code analysis tools and get the same errors that are shown on the developers hosts. Or to get the msbuild log messages in the good format.

Good luck, and make me a sign if I can help you.
Ivo


--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/71116942-198b-4a97-bc5a-9fbc8a422c38%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

rezaetezal

unread,
Sep 2, 2017, 4:56:18 PM9/2/17
to jenkins...@googlegroups.com
Thank you for your reply.

This was caused by the interdependent projects not referencing the DLL files
they were using (which were the output of other projects) directly. A change
was made to the references that has made the builds succeed.

I am still not sure why the same commands would fail only from the pipeline
build and nowhere else.

Off to buy Rogaine.

Cheers



--
Sent from: http://jenkins-ci.361315.n4.nabble.com/Jenkins-users-f361316.html
Reply all
Reply to author
Forward
0 new messages