As a part of code quality we run svn update followed by msbuild.exe "project.sln" /t:Build /m:1 /clp:ErrorsOnly" and thereafter msbuild sonarqube runner. Few times I receive error mentioned below and upon investigating code checkout folder finds a merge conflict. As am only using svn update what would be the cause of same to be noted that on revert project gets executed fine and there are no conflicts in svn repo
ERROR LOG
Microsoft (R) Build Engine version 14.0.24720.0
Copyright (C) Microsoft Corporation. All rights reserved.
Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch.
C:\Program Files\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(4381,5): error MSB3541: Files has invalid value "<<<<<<< .mine". Illegal characters in path. [D:\SNRProjs\Scheduler.Business.csproj]
Solution in comments by Freddy - SonarSource Team worked for me. Use of new Sonarqube Scanner for MSBUILD required.
Related
When attempting to build Boost 1.69.0 from a fresh, clean, checkout, on Windows 10, using Visual Studio 2017, I encounter the following confounding error message:
**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.0
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'
C:/90cf73ea/tools/boost_install/.\boost-install-dirs.jam:15: in boost-install-dirs.includedir
ERROR: rule "package.paths" unknown in module "boost-install-dirs".
C:/90cf73ea/libs/headers/build/../../../tools/boost_install\boost-install.jam:721: in boost-install.install-cmake-config
libs\headers\build\Jamfile:87: in modules.load
C:/90cf73ea/tools/build/src/build\project.jam:375: in load-jamfile
C:/90cf73ea/tools/build/src/build\project.jam:64: in load
C:/90cf73ea/tools/build/src/build\project.jam:89: in load-used-projects
C:/90cf73ea/tools/build/src/build\project.jam:75: in load
C:/90cf73ea/tools/build/src/build\project.jam:145: in project.find
C:/90cf73ea/tools/build/src\build-system.jam:618: in load
C:\90cf73ea\tools\build\src/kernel\modules.jam:295: in import
C:\90cf73ea\tools\build\src/kernel/bootstrap.jam:139: in boost-build
C:\90cf73ea\boost-build.jam:17: in module scope
I am executing the build commands from the VS2017 command prompt. I am able to execute "bootstrap.bat" without any issues. Running "b2.exe toolset=msvc-14.1" (regardless of any further arguments) results in the above error message. How can I go about diagnosing and/or resolving this error?
FYI, in my case, I had cloned the Boost repo (currently at 1.70.0). Tried to build and got this error. I then did a "git status" and found a bunch of libraries that were untracked (presumably from the 1.70.0 branch). Removing all untracked directories allowed me to build.
Hope that helps someone!
I don't remotely understand why this would be the case, but I solved this issue by updating git from version 2.18.0 to version 2.20.1.
I got this advice on the boost build mailing list:
This error indicates that the the build submodule is not up-to-date.
- Steven Watanbe
I speculate that something in git version 2.18.0 struggled with the boost build submodule. Moral of the story seems to be, check if your git version needs to be updated.
I might be missing something really simple here. I'm trying to build a solution in Teamcity using msbuild but it always keeps failing with the below error.
'msbuild' is not recognized as an internal or external command,
operable program or batch file.
I have VS2017 installed and when I run the solution locally through command line on the same Teamcity agent, it works perfectly with the following comments.
Microsoft (R) Build Engine version 15.4.8.50001 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
But for some reason it always fails on teamcity. I'm at a loss as to what am I missing here. Any pointers are greatly appreciated.
Following is the command that I'm using to compile the solution
msbuild hello.sln /t:Rebuild
msbuild fails in Teamcity
Agree with stijn. According to the error log, it seems MSBuild not in the default path, so it could not be found.
To resolve this issue, you should make sure you have installed the Visual Studio 2017 or Microsoft Build Tools on the teamcity agent and need to properly configure your build runner, especially MSBuild version.
Besides, you can also try to create environment variable "MSBuild" and set it to the path of MSBuild.exe in your teamcity agent.
The default path of MSBuild for Visual Studio 2017 is:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin
If above not help you, please share us your configuration about Build Runner.
I have an existing XAML build I am porting over to Visual Studio Team Services build. There is a Solution file that contains two wixproj projects, and this builds with no issues on the current (legacy XAML) Hosted Build Controller (which uses WiX Toolset v3.7).
In VS TS, I created a new build process and added a step to Build solution using a Visual Studio Build step. I have set the Solution path to my sln that contains the two wixproj projects. All the other options are the defaults except the timeout which is set to 10 minutes.
The build step initiates but times out after calling the Light.exe step, as in the log below:
PrepareForBuild:
Creating directory "obj\Debug\".
Creating directory "bin\Debug\".
Compile:
C:\Program Files (x86)\WiX Toolset v3.10\bin\candle.exe -dDebug ...
Windows Installer XML Toolset Compiler version 3.10.3.3007
Copyright (c) .NET Foundation and contributors. All rights reserved.
{myfile}.wxs
Link:
C:\Program Files (x86)\WiX Toolset v3.10\bin\Light.exe -out ...
Windows Installer XML Toolset Linker version 3.10.3.3007
Copyright (c) .NET Foundation and contributors. All rights reserved.
##[error]The task has timed out.
The build will run 10 minutes and then throw a timeout error. It usually takes ~1 minute to finish. There is no information in the log about where this may be timing out or why.
I see that VS TS Build uses WiX version 3.10, but WiX version 3.10 works for me locally to build this same sln. I haveve tried all options for Visual Studio Version in the build step with same results.
Any ideas what I am missing and why this isn't working?
I found a post in the wixtoolset GitHub project documenting a bug in WiX 3.10 about deadlocks occurring with WiX projects if there are any warning or error messages generated during the build.
The workaround is to add the following MSBuild Arguments in the build step:
/p:RunWixToolsOutOfProc=true
This resolved my issue with the Light.exe process timing out.
Files (x86)\WiX Toolset v3.10\bin\candle.exe -dDebug ...
Windows Installer XML Toolset Compiler version 3.10.3.3007
Copyright (c) .NET Foundation and contributors. All rights reserved.
{myfile}.wxs
Link:
C:\Program Files (x86)\WiX Toolset v3.10\bin\Light.exe -out ...
Windows Installer XML Toolset
I have a Visual Studio Solution with one SSIS Project with a number of connection managers and packages. It builds fine in Visual Studio. It fails in our build automation system being built via the devenv command line:
"D:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.com" ADSMetricsETL.sln /Build Release /Project "ADSMetricsETL"
Microsoft (R) Microsoft Visual Studio 2012 Version 11.0.61030.0.
Copyright (C) Microsoft Corp. All rights reserved.
------ Build started: Project: ADSMetricsETL, Configuration: Debug ------
========== Build: 0 succeeded or up-to-date, 1 failed, 0 skipped =========
command exit code: 1
I get no errors from the build, just the "1 failed". I don't see any options on devenv to increase the verbosity. This solution used to build find in the build automation system. I made a couple of minor changes to one package and now it doesn't build at all.
Also, never noticed this before but why when the command line says "/Build Release" is it building "Configuration: Debug"?
Any thoughts?
One of the Connection Managers was inadvertently updated in the process. It would have been helpful if the Build gave me some indication of the error. I had to go back through the Subversion logs and inspect everything listed as changed. When I saw the Connection Manager listed I said "Huh? I didn't make changes to that Connection Manager..." I reverted the Connection Manager, committed everything and now it builds.
When I type...
Msbuild<Enter>
...at the command prompt, I get...
Microsoft (R) Build Engine Version 2.0.50727.4927
[Microsoft .NET Framework, Version 2.0.50727.4927]
Copyright (C) Microsoft Corporation 2005. All rights reserved.
This is all very well and good except that when I run this against a Visual Studio 2010 .sln file, the error message indicates:
MyProject.sln(2): Solution file error MSB5014: File format version is not recognized. MSBuild can only read solution files between versions 7.0 and 9.0, inclusive.
0 Warning(s)
1 Error(s)
It would appear that the version of MSBuild that is being called, is not capable of understanding my solution file.
I figured that I would check out my path and see where MSBuild is being picked up from. However, it seems that no part of my path points at a location where MSBuild is to be found.
How is the command line finding the copy of MSBuild that it is using and how can I change this version so that the latest version is used?
I found this question as my PATH variable did not contain a reference to MSBuild.exe. In case anyone else is having this issue, my resolution was to explictly register the environment variables for Visual Studio tools from the command prompt:
"%VS100COMNTOOLS%"\\vsvars32.bat // VS2010 environment variables
"%VS110COMNTOOLS%"\\vsvars32.bat // VS2012 environment variables
"%VS120COMNTOOLS%"\\vsvars32.bat // VS2013 environment variables
MSBuild.exe is now registered in PATH
where msbuild
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe
It must be somewhere in the PATH environment. Use 'where msbuild' to determine where it is loading msbuild from.
Use the Visual Studio Command Prompt (2010) shortcut to initialize the path and other environment variables for VS 2010 and MSBuild 4.0.
Change your environment variables.
Find/set your MSBuild path variable to be C:\Windows\Microsoft.NET\Framework\v4.0.30319
Obiviously the above path will depend on your installation location, but it will be close if not exact.
For building a C# 6 project, this worked for me in a batch file
if exist "%ProgramFiles(x86)%\MSBuild\14.0\bin" set MSBUILDLOCATION=%ProgramFiles(x86)%\MSBuild\14.0\bin
if exist "%ProgramFiles%\MSBuild\14.0\bin" set MSBUILDLOCATION=%ProgramFiles%\MSBuild\14.0\bin
"%MSBUILDLOCATION%\msbuild.exe" "path\to\my\project.csproj"
You can easily change the version number (14.0) or add lines with more version numbers (12.0 and 4.0 for example) if you wanted to support a range of versions.