I have written a batch file, which when executed builds a visual studio solution. The solution comprises of few C# projects. I am using MSBuild utility for this. How can i stop the build from proceeding further when there are compilation errors in any of the projects?
Further how can i get the error messages and display them on command prompt?
There's no support for stop on first failure when building a visual studio solution.
You can workaround this by taking the following steps:
Set the environment variable msbuildemitsolution to 1 (set msbuildemitsolution=1);
Invoke MSBuild in order to generate a *.proj file from the target VS solution;
In the generated *.sln.proj file change RunEachTargetSeparately="true" in the target named Build to RunEachTargetSeparately="false";
Invoke MSBuild to build the updated *.sln.proj file.
This answer is based on Dan Moseley answer to a post on MSDN Forums.
It would be easier to give you an answer if you would have posted relevant parts of your batch file. Nevertheless, for your second part of the question, here is an example how I solved almost the same issue in one of our build scripts:
msbuild.exe /m /p:Configuration=Release /v:n theSolutionFile.sln >Build.log
if ERRORLEVEL 1 goto :showerror
find "0 Warn" Build.log >nul:
if ERRORLEVEL 1 goto :showerror
goto :EOF
:showerror
echo Build error occurred
exit %ERRORLEVEL%
Related
I have a TFS xaml Build template that runs the msbuild.sonarqube.runner start (and end) before and (after the) msbuild task in the xaml.
It all works well enough with a .sln file. As the file under build.
However, when I attempt to use this on a build that runs msbuild on a .csproj file the end process reports that it cannot find the postprocess exe.
"Execution failed. The specified executable does not exist: .sonarqube\bin\MSBuild.SonarQube.Internal.PostProcess.exe"
there no error indication given by the Start command.
is there something special I need to do to get this to work, or is this a limitation of the MSBuild runner?
Please help.
My whole team is keen to use the tool, but as it is only a fraction of the existing builds are being analyzed
thanks
Jeff Gedney
The begin and end commands of the SonarQube Scanner for MSBuild, as well as all msbuild commands MUST be launched from the same current working directory. Indeed, they will all need access to the .sonarqube folder that is created by the begin command.
Other than that, you can launch MSBuild on a *.csproj file instead of a *.sln if you prefer - that is supported by the SonarQube Scanner for MSBuild.
I've created the following ticket to improve the error message in case end is launched from the wrong folder: https://jira.sonarsource.com/browse/SONARMSBRU-160
Make sure you put yourself in the root folder of the project you want to analyze, then run the following commands:
a.MSBuild.SonarQube.Runner.exe begin /k:"sonarqube_project_key" /n:"sonarqube_project_name" /v:"sonarqube_project_version"
b.Build the project, for example: msbuild /t:Rebuild
c.MSBuild.SonarQube.Runner.exe end
Check:http://docs.sonarqube.org/display/PLUG/C%23+Plugin
When I run my TeamCity build with the only build step being of runner type Visual Studio (sln), I get the following error:
C:\TeamCity\buildAgent\work\4978ec6ee0ade5b4\Test\Code\Test.sln(2, 1): error MSB4025: The project file could not be loaded. Data at the root level is invalid. Line 2, position 1.
This is on a dedicated CI server running TeamCity Professional 8.1.1 (build 29939). There are several other successfully-running builds on this server.
The odd bit is that the same build runs successfully on TeamCity on my dev machine. I followed an answer to a similar question, and copied the specified folders across, but that didn't help.
I'm sure the project/solution file isn't invalid because in addition to the build running on my dev box, I have opened the solution in Visual Studio and built it there with no problems.
Any suggestions?
I just fixed this.
Look inside the Test.sln file for Project or EndProject tags that aren't closed. For us, the EndProject was missing and it broke on teamcity, but no issues in Visual Studio.
It seems the TeamCity error message will occur for any number of root causes. In my case the problem occurred because a line inside the GlobalSection(NestedProjects) section was referring to a project Guid which didn't relate to any project defined in the Solution file.
As with the previous post I didn't have any issues building in Visual Studio. I only got a more helpful error message that allowed me to discover what the real problem was when I built using msbuild.
See https://therightjoin.wordpress.com/2014/07/04/msb4025-the-project-file-could-not-be-loaded-data-at-the-root-level-is-invalid-error-when-building-ssdt-project-in-teamcity for another example, and where using msbuild helped identify the true problem.
In our case, it was a duplicate project reference in the solution file (caused by near simultaneous commits and an automatic merge).
In our situation the problem was specifying a ToolsVersion that was not installed on that machine. (14 which VS2015 has but VS2017 does not have by default)
In my case, after merging, in .sln file, it was a mismatch of lines under
GlobalSection(NestedProjects) = preSolution
{6B971E15-6B61-4AA8-9B93-9639C23269C3} = {9A14E7EF-3FA1-4B9A-B413-C550B3E5AC62}
{54D14F01-D576-4DE6-9404-D21AD0DC4916} = {9A14E7EF-3FA1-4B9A-B413-C550B3E5AC62}
... (was some extra entry here )
...
EndGlobalSection
section. In clear words, there were some extra lines added after merging. So, If you have merged, please compare two solution files manually. You can start with total line numbers in both files.
In another Case
We had a blank lines - so make sure any blank lines are removed!
Hope this helps some else too!
I got this same error with Jenkins. It turns out the root Jenkins folder was set to C:\Program Files (x86)\ and it didn't have write access to bin and obj directories.
Error:
error MSB4025: The project file could not be loaded. Data at the root level is invalid.
I launched cmd as Administrator and ran this:
"C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" "C:\Program Files (x86)\Jenkins\workspace\BuildBI_1\Reports\Test\ReportsTests.sln" /t:Build /p:RunOctoPack=true
And that gave me clues about not being able to write to bin and obj.
This worked for me-
You can install Build Tools for Visual Studio 2017, make sure to select C++ tools, Windows 10 SDK and MSBuild and your set.
Use MSBuild to identify the underlying problem:
$> msbuild mysolution.sln
Gave me this beauty with the correct error line number:
If msbuild cannot be accessed like that from the command line / powershell, try to find the MSBuild.exe shipped with VisualStudio, e.g. C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\amd64\MSBuild.exe.
VisualStudio itself seems to be very "tolerant" against errors / inconsistencies in the solution file, so having it open in VS is no guarantee for the sln file being correct.
I fixed it by updating the solution file.
Another possible problem (and resolution): I had a stray unused solution file in my repo, pointing to who-knows-where, and the MSBUILD step in my Azure DevOps pipeline was set to **\*.sln.
I'm attempting to do a command line package deploy for our Windows Store Application.
My command line instructions are:
msbuild /m /p:Configuration=Debug /p:Platform=x86 /target:Build
I'm using VS2013 Professional with Windows 8.1
I get the following error:
C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v12.0\AppxPackage\Microsoft.AppXPackage.Targets(1224,9):
error APPX0002: Task 'GenerateAppxPackageRecipe' failed. Value cannot
be null.\r [C:\Path\Project.csproj]
C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v12.0\AppxPackage\Microsoft.AppXPackage.Targets(1224,9):
error APPX0002: Parameter name: source\r [C:\Path\Project.csproj]
How should I resolve this?
This error was resolved by using the correct version of msbuild.exe
On a clean build server with VS2013 installed, there are (at least) two copies of msbuild.exe installed. In our case the install locations were:
C:\Program Files (x86)\MSBuild\12.0\Bin\msbuild.exe
and
C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe
The one in the .Net Framework folder was the one that gave us the errors. Using the version installed in the Program Files folder resolved the issue.
It's impossible to help you without having the code which can reproduce the error. I suspect some property does not resolve correctly when building outside VS(eg VisualStudioVersion) and needs to be passed from command line. VS also uses msbuild to build your projects, so comparing build logs from VS and CMD should help you track down the problem.
I suggest, that you set visual studio's build output verbosity to diagnostic, clean solution, than build and capture the build log.
Then clean solution and build from command line with verbosity set to diagnostic and /fl switch(log to file, because diagnostic build log is way too long to analyse in console window).
Compare command-line output to VS output. Look for the differences. With diagnostic level of verbosity, chances are, you'll find out what's missing (I had similar issues with database projects failing to build from cmd due to VisualStudioVersion variable not being resolved correctly, so I passed it from command line).
NB: diagnostic log is very verbose which makes analysis hard: I'd start from detailed verbosity level.
I have deleted all files/folders from "project"/bin folder, cleaned the solution and rebuild with success !
For those facing the issue on hybrid app (corodova in my case), delete the build folder manually and re-build from VS.
Standard clean solution didn't do the job.
I'm using team city to make an automatic deploy and MSBuild won't work...
In the build step the the command line parameters look like this:
ProjectName.deploy.cmd /y /M:https://[WebDeployUrl:8172]/MsDeploy.axd /u:username /p:password –allowUntrusted /A:basic
this works fine from my machine, but the build server fails with the following response:
[MSBuild output] MSBUILD : error MSB1001: Unknown switch.
[MSBuild output] Switch: /Y
Anyone has an idea about this?
This is a very old question, and the asker likely sorted out their issue long ago, but here goes anyways:
MSBuild tasks in TeamCity require a commandline that pertain to MSBuild.exe specifically, IIRC.
That is, TeamCity is executing MSBuild.exe with the parameters you've given it like so:
msbuild.exe ProjectName.deploy.cmd /y /M:https://[WebDeployURL]:8172]/MsDeploy.axd /u:username /p:password -allowUntrusted /A:basic
Of course, MSbuild has no idea what those switches are, nor would it be able to process 'ProjectName.deploy.cmd' as an MSBuild file.
I've started using Code Contracts in all new code I'm writing, such as in a framework library I'm building to help bootstrap IoC, O/RM, etc., in an ASP.NET MVC application. I've written a simple build script for this framework library that looks like the following:
#echo off
echo.
echo Cleaning build output (removing 'obj' and 'bin' folders)...
for /f "tokens=*" %%G in ('dir /b /ad /s bin') do rmdir /s /q "%%G"
for /f "tokens=*" %%G in ('dir /b /ad /s obj') do rmdir /s /q "%%G"
rmdir /s /q build
echo.
echo Starting the build...
call "%VS100COMNTOOLS%\vsvars32.bat"
msbuild Integration.build /target:Build
echo.
echo Done!
pause
This doesn't work. What I end up with in my build folder if I run this is, for whatever reason, assemblies that aren't fully rewritten by ccrewrite alongside .pdb.original, .rewritten and .csproj.FileListAbsolute.txt files that litter the output directory.
What does work is first building the solution in Visual Studio 2010, commenting out line 3 through 7 in the batch file and running it again. I then end up with properly rewritten assemblies and no .pdb.original nor .rewritten files.
What I've deduced from this is that Visual Studio 2010 somehow triggers the Code Contract rewriter properly so the resulting assemblies from the Visual Studio 2010 build is re-used by the command-line MSBuild call, so what my batch script basically does is just copying files to the build directory. Rather useless, in other words.
I've read this, but Jon's problem seems different from mine since ccrewrite is obviously doing something, but it's just not completing the rewriting for whatever reason. The Integration.build file builds the correct configuration (that has Code Contracts enabled in the .csproj files) and everything else looks right, it just doesn't work properly.
So, I'm wondering: How do I run MSBuild the way Visual Studio 2010 is where ccrewrite does what it's supposed to and doesn't litter my output directory with .rewritten and .pdb.original files? Does anyone have a perfect example of how an MSBuild file doing proper Code Contracts rewriting looks like?
The answer is in the script. All Visual Studio is ever going to do is run MSBuild tasks that will invoke others. One thing you can do is go to Tools|Options|Build... and turn on logging so you can see in detail which bit is doing what to generate the artifacts.
How would one do such a complex and involved thing? Read a guide to MSBuild such as Hashimi p1 and Part 2.
Then dig into the source for the build in e.g.:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets
The best way to get there is to open your .csproj and look what it includes and go via that (the .CSharp.targets is the first one - the one I cited comes further down the stack).
(That and wait for someone to pop in with an actual answer!)
I've played a little with Code Contract's static analysis and it is pretty cool.
Now trying to set up TeamCity build ...
Here is msbuild integration info from Microsoft Research (see page 44)