Develop Reference

How do I solve error MSB4041 (VS2017, C#, MSBuild, SpecFlow.Tools.MsBuild.Generation, SpecRun)?

I have an automation test suite, attempting to use SpecRun to run tests in parallel. It appears that rather than being able to run tests in Test Explorer, I need to instead run them using the provided "runtests.cmd" file...
#pushd %~dp0
#where /q msbuild
#IF ERRORLEVEL 1 (
echo "MSBuild is not in your PATH. Please use a developer command prompt!"
goto :end
) ELSE (
MSBuild.exe "C:\Users\me\source\repos\OurAutomation\src\OurAutomation.csproj"
)
#if ERRORLEVEL 1 goto end
#cd ..\packages\SpecRun.Runner.*\tools\net45
#set profile=%1
#if "%profile%" == "" set profile=Default
#if exist "%~dp0\bin\Debug\%profile%.srprofile" (
SpecRun.exe run "%profile%.srprofile" --baseFolder "%~dp0\bin\Debug" --log "specrun.log" %2 %3 %4 %5
) else (
SpecRun.exe run --baseFolder "%~dp0\bin\Debug" --log "specrun.log" %2 %3 %4 %5
)
:end
#popd
pause
...the pause statement is something I added in to keep the console open to see the errors.
The errors are:
Microsoft (R) Build Engine version 4.7.3056.0
[Microsoft .NET Framework, version 4.0.30319.42000]
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 08/07/2019 11:15:06.
Project "C:\Users\me\source\repos\OurAutomation\src\OurAutomation.csproj" on node 1 (defau
lt targets).
C:\Users\me\source\repos\OurAutomation\src\packages\SpecFlow.Tools.MsBuild.Generation.3.0.220\build\Sp
ecFlow.Tools.MsBuild.Generation.props(1,1): error MSB4041: The default XML namespace of the project must be the MSBuild
XML namespace. If the project is authored in the MSBuild 2003 format, please add xmlns="http://schemas.microsoft.com/d
eveloper/msbuild/2003" to the <Project> element. If the project has been authored in the old 1.0 or 1.2 format, please
convert it to MSBuild 2003 format. [C:\Users\me\source\repos\OurAutomation\src\OurAutomati
on.csproj]
Done Building Project "C:\Users\me\source\repos\OurAutomation\src\OurAutomation.csproj" (d
efault targets) -- FAILED.
Build FAILED.
"C:\Users\me\source\repos\OurAutomation\src\OurAutomation.csproj" (default target) (1) ->
C:\Users\me\source\repos\OurAutomation\src\packages\SpecFlow.Tools.MsBuild.Generation.3.0.220\build\
SpecFlow.Tools.MsBuild.Generation.props(1,1): error MSB4041: The default XML namespace of the project must be the MSBui
ld XML namespace. If the project is authored in the MSBuild 2003 format, please add xmlns="http://schemas.microsoft.com
/developer/msbuild/2003" to the <Project> element. If the project has been authored in the old 1.0 or 1.2 format, pleas
e convert it to MSBuild 2003 format. [C:\Users\me\source\repos\OurAutomation\src\OurAutoma
tion.csproj]
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:00.02
I've set the system environment variable PATH to look for MSBuild.exe in C:\Windows\Microsoft.NET\Framework\v4.0.30319 (this is the latest version I have).
I tried to do as the error suggested, and found that both OurAutomation.csproj and OurAutomation.csproj.user files already have:
<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
So that's the simple fix out of the way - no fix at all, because the Project tag already has the required attribute and value!
I've been on several websites looking for an alternative solution. Others are saying that they had this problem when upgrading from VS2015 to 2017 (they changed from using project.json to *.csproj). However I have not upgraded. I created my project in VS2017. Target framework: .NET Framework 4.7.2, Output type: Class Library.
Not sure if SpecFlow.Tools.MsBuild.Generation is introducing a conflict here, but I do need it.
Please do you know how I would go about fixing this? Running out of ideas.
Thank you.

Pavel Anikhouski's answer was the solution, thank you!
"Starting from VisualStudio 2015 MSBuild is provided as part of IDE (or build tools), you should use this version, e.g. c:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\".

Deploy a C# Stateful Service Fabric application from Visual Studio to Linux

EDIT 04/06/18 => Updated question with last status
So I have this working .Net 4.6 Stateful Service that currently run on my Windows Service Fabric cluster deployed on Azure.
Starting from 09/2017, I should be able to move to Linux: https://blogs.msdn.microsoft.com/azureservicefabric/2017/09/25/service-fabric-6-0-release/
So I'm trying to deploy it on Linux so I can save costs.
First things first, I've migrated all my code from .Net 4.6 to .Net Core 2.0. Now I can compile my binaries without issues. I've basically created new .Net Core projects and then moved all my source code from .Net 4.6 projects to the new .Net Core ones.
Then I've updated my Service Fabric application. I removed my previous SF services from my sfproj, then I've added my new .Net Core ones.
Looks like there is a warning (nothing on the output window though), but it's here anyway if I try to create a new empty Statful service using .Net core 2.0 through the template provided by Service Fabric Tools 2.0 (beta):
So I'm going to live with it.
On my dev machine, I've modified the 2 csproj projects that contain my Stateful services so they can run locally as Windows executables. I've used the win7-x64 runtimeIdentifier.
Running my SF cluster locally on my Windows machine is fine.
Then I've slightly changed the previous csproj files for Linux. I used the ubuntu.16.10-x64 runtimeIdentifier.
Also I've changed the ServiceManifest.xml file to target the linux-compatible binary:
<!-- Code package is your service executable. -->
<CodePackage Name="Code" Version="1.9.6">
<EntryPoint>
<ExeHost>
<Program>entryPoint.sh</Program>
</ExeHost>
</EntryPoint>
</CodePackage>
entryPoint.sh is a basic script that eventually executes:
dotnet $DIR/MyService.dll
Then I've successfully deployed to my secured SF Linux cluster from Visual Studio. Unfortunately I have the following errors for both my stateful services:
Error event: SourceId='System.Hosting',
Property='CodePackageActivation:Code:EntryPoint'. There was an error
during CodePackage activation.The service host terminated with exit
code:134
Looks like my binary crashes when starting. So here are my questions:
Is the approach right to deploy a C# .Net Core SF stateful service on Linux from Visual Studio?
EDIT: looking inside the LinuxsyslogVer2v0 table, I get the following error:
starthost.sh[100041]: Unhandled Exception:
System.IO.FileLoadException: Could not load file or assembly
'System.Threading.Thread, Version=4.1.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a'. The located assembly's manifest
definition does not match the assembly reference. (Exception from
HRESULT: 0x80131040)
I found the following bug report: https://github.com/dotnet/sdk/issues/1502
Unfortunately, I still get the error without using MSBuild (using dotnet deploy).
EDIT: further clarification:
My boss want me to run on Linux because starting from D1v2 machines, it's half the price compared to Windows machines (no license etc.)
My .NET Core 2.0 services successfully run on Windows. So the .NET Core port should be fine.

So, this was a real pain in the ass to get it working properly. But it works. Well, kind of.
First, Reliable Services are still in preview on Linux: https://github.com/Microsoft/service-fabric/issues/71
Full Linux support should come very soon (actually it should be available already according to the previous link...).
Now for the details about how to procede, here is some information to help others, because there is just nothing about that on Microsoft documentation and I literally lost 3 days trying to make it work.
1. Do use .NET Core 2.0 for your projects.
It is supported on Linux. On preview for now, but it works.
2. Do use the right RID for your projects.
As of today (April 2018), the right RID to use is ubuntu.16.04-x64.
Edit the csproj files of your Reliable Service projects and set the RID like this:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
<IsServiceFabricServiceProject>True</IsServiceFabricServiceProject>
<RuntimeIdentifier>ubuntu.16.04-x64</RuntimeIdentifier>
<Platforms>AnyCPU;x64</Platforms>
</PropertyGroup>
The fun part is, you should be able to provide multiple RIDs using the RuntimeIdentifiers parameter (with a S at the end) like that:
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
<IsServiceFabricServiceProject>True</IsServiceFabricServiceProject>
<RuntimeIdentifiers>win7x64;ubuntu.16.04-x64</RuntimeIdentifiers>
<Platforms>AnyCPU;x64</Platforms>
</PropertyGroup>
So you could build Windows binaries and Linux binaries at the same time.
But it simply doesn't work. When building the project from Visual Studio, I end up with the following directory only:
bin/Debug/netcoreapp2.0/
Only DLLs, no valid entry point. No win7-x64 folder, no ubuntu.16.04-x64, no nothing.
This is a bug, supposed to be fixed, but it's not (I use Visual Studio 15.6.2 all up-to-date as of today). See https://github.com/dotnet/core/issues/1039
3. You need a valid Entry Point for your service.
On Windows it's an executable file (*.exe). On Linux it's not. I ended up getting the Linux C# example and copied/pasted the entry point. https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-create-your-first-linux-application-with-csharp
So basically I now have on my ServiceManifest.xml file of each Reliable Service the following EntryPoint :
<?xml version="1.0" encoding="utf-8"?>
<ServiceManifest Name="XXXX"
Version="1.0.0"
xmlns="http://schemas.microsoft.com/2011/01/fabric"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ServiceTypes>
<!-- This is the name of your ServiceType.
This name must match the string used in RegisterServiceType call in Program.cs. -->
<StatefulServiceType ServiceTypeName="YYY" HasPersistedState="true" />
</ServiceTypes>
<!-- Code package is your service executable. -->
<CodePackage Name="Code" Version="1.0.0">
<EntryPoint>
<ExeHost>
<Program>entryPoint.sh</Program>
</ExeHost>
</EntryPoint>
</CodePackage>
entryPoint.sh is as follows:
#!/usr/bin/env bash
check_errs()
{
# Function. Parameter 1 is the return code
if [ "${1}" -ne "0" ]; then
# make our script exit with the right error code.
exit ${1}
fi
}
DIR=`dirname $0`
echo 0x3f > /proc/self/coredump_filter
source $DIR/dotnet-include.sh
dotnet $DIR/NAME_OF_YOUR_SERVICE_DLL.dll $#
check_errs $?
dotnet-include.sh is as follows:
#!/bin/bash
. /etc/os-release
linuxDistrib=$ID
if [ $linuxDistrib = "rhel" ]; then
source scl_source enable rh-dotnet20
exitCode=$?
if [ $exitCode != 0 ]; then
echo "Failed: source scl_source enable rh-dotnet20 : ExitCode: $exitCode"
exit $exitCode
fi
fi
Both are inside the PackageRoot folder. I specified for both their properties so the Build Action is "Content" and the Copy to Output Directory is "Copy always".
4. Do NOT build using MSBuild !!
Yeah it is supposed to build Linux packages too, or at least it seems so, because MSBuild is able to produce the following files when you right click on your project and click "Build":
Don't trust the apparent success of the operation, it will miserably FAIL to properly execute when deployed. Some *.so files missing and other issues. MSBuild is buggy as hell and misbehaves regarding dependencies.
See for instance this bug report: https://github.com/dotnet/sdk/issues/1502
Still not fixed after almost a year...
Or https://github.com/dotnet/core/issues/977 (got this one, too).
5. Do write some PowerShell script to build the stuff by yourself.
I ended up reinventing the wheel using the following script to build my package:
# Creating binaries for service 1
cd DIRECTORY_OF_MY_SERVICE_1
dotnet publish -c Release -r ubuntu.16.04-x64
# Creating binaries for service 2
cd ..\DIRECTORY_OF_MY_SERVICE_2
dotnet publish -c Release -r ubuntu.16.04-x64
# Creating binaries for service 3
cd ..\DIRECTORY_OF_MY_SERVICE_3
dotnet publish -c Release -r ubuntu.16.04-x64
# Copying ApplicationManifest.xml
cd ..
mkdir PKG\ServiceFabricApplication
echo F|xcopy "ServiceFabricApplication\ApplicationPackageRoot\ApplicationManifest.xml" "PKG\ServiceFabricApplication\ApplicationManifest.xml" /sy
# Copying Service1 files
mkdir "PKG\ServiceFabricApplication\Service1Pkg"
mkdir "PKG\ServiceFabricApplication\Service1Pkg\Code"
xcopy "Service1\PackageRoot\*" "PKG\ServiceFabricApplication\Service1Pkg" /sy /D
xcopy "Service1\bin\Release\netcoreapp2.0\ubuntu.16.04-x64\publish\*" "PKG\ServiceFabricApplication\Service1Pkg\Code" /sy
# Copying Service2 files
mkdir "PKG\ServiceFabricApplication\Service2Pkg"
mkdir "PKG\ServiceFabricApplication\Service2Pkg\Code"
xcopy "Service2\PackageRoot\*" "PKG\ServiceFabricApplication\Service2Pkg" /sy /D
xcopy "Service2\bin\Release\netcoreapp2.0\ubuntu.16.04-x64\publish\*" "PKG\ServiceFabricApplication\Service2Pkg\Code" /sy
# Copying Service3 files
mkdir "PKG\ServiceFabricApplication\Service3Pkg"
mkdir "PKG\ServiceFabricApplication\Service3Pkg\Code"
xcopy "Service3\PackageRoot\*" "PKG\ServiceFabricApplication\Service3Pkg" /sy /D
xcopy "Service3\bin\Release\netcoreapp2.0\ubuntu.16.04-x64\publish\*" "PKG\ServiceFabricApplication\Service3Pkg\Code" /sy
# Compresses the package
Write-host "Compressing package..."
Copy-ServiceFabricApplicationPackage -ApplicationPackagePath .\PKG\ServiceFabricApplication -CompressPackage -SkipCopy
sfproj file is a Visual Studio / MSBuild related project, so you need to build everything by yourself.
The script above produces the same content as the pkg folder created by MSBuild when building your sfproj using Visual Studio. It copies everything on a PKG folder at the root of your solution.
The package structure is detailed here: https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/service-fabric/service-fabric-package-apps.md
6. Now it's time to deploy!
At this point I didn't trusted Visual Studio anymore, so I built my own PowerShell script:
. .\ServiceFabricApplication\Scripts\Deploy-FabricApplication.ps1 -ApplicationPackagePath '.\PKG\ServiceFabricApplication' -PublishProfileFile '.\ServiceFabricApplication\PublishProfiles\Cloud.xml' -DeployOnly:$false -ApplicationParameter:#{} -UnregisterUnusedApplicationVersionsAfterUpgrade $false -OverrideUpgradeBehavior 'None' -OverwriteBehavior 'SameAppTypeAndVersion' -SkipPackageValidation:$false -ErrorAction Stop
It reuses the Deploy-FabricApplication.ps1 script provided by the Service Fabric project template inside the sfproj project. This script parses the Cloud.xml PublishProfile and deploys to your service fabric cluster.
So you specifies the rights values on both PublishProfiles/Cloud.xml and ApplicationParameters/Cloud.xml then execute the script.
It only works if you have the certificate used to secure the cluster installed on your machine, of course.
Do note the first dot '.' is important, because if you don't use it, you'll have the following error:
Get-ServiceFabricClusterManifest : Cluster connection instance is null
See https://stackoverflow.com/a/38104087/870604
Oh, and as there are bugs on the Service Fabric SDK too, you might want to shutdown your local SF cluster too...
https://github.com/Azure/service-fabric-issues/issues/821
7. Now it's time for another deception.
It simply doesn't work, the service crashes on startup. After searching hours inside the LinuxsyslogVer2v0 Azure Storage table (the log table for Linux, located in one of the two Azure Storage Accounts created automatically with the SF cluster), I found that Microsoft own Nuget Packages were buggy too.
Specifically, the Nuget package Microsoft.Azure.Devices doesn't work on version 1.6.0. An issue with a reference of a dll not found or whatever. I rollbacked to a previous version, namely 1.5.1, and it was fixed.
At this point I didn't had anymore energy to create another Github issue about that. Sorry MS, I'm not your QA team, I'm getting tired.
8. Build again using the first PowerShell script, deploy using the second PowerShell script, and you're done.
You've finally deployed C# Reliable Services using .NET Core 2.0 from Visual Studio (kind of, as it's buggy and I used PowerShell) on Windows to a Linux SF Cluster.
Now I still have issues with my ASP.NET Core service, but it will be a story for another day.
Conclusion: TL;DR
The whole thing is a mess. Bugs everywhere. In the SDK, in the tools, in some of Microsoft Nuget Packages. Awful experience. But it is supported (in preview for now) and you can make it work. Hope this post will help...

I was having similar issues, but I believe this is the issue:
In this release, .NET Core 2.0 services are only supported on Service Fabric for Windows. Full cross-platform support for .NET Core 2.0 services on Windows and Linux is coming soon.
From the Service Fabric 6.1 Release Notes
So no Linux as long as you are targeting .net core 2.0.

I have success deploy to Linux service fabric with this help
Open all the service .csproj files and update the RuntimeIdentifier as shown below
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
<IsServiceFabricServiceProject>True</IsServiceFabricServiceProject>
<RuntimeIdentifier>linux-x64</RuntimeIdentifier>
</PropertyGroup>
Update the ServiceManifest.xml to remove .exe extension as shown below
<CodePackage Name="Code" Version="1.0.0">
<EntryPoint>
<ExeHost>
<Program>Web1</Program>
</ExeHost>
</EntryPoint>
</CodePackage>
See https://blogs.msdn.microsoft.com/premier_developer/2018/05/27/running-net-core-2-0-applications-in-a-linux-service-fabric-cluster-on-azure/
*Visual Studio 15.7.3

Mono - Building/running Microsoft Compact Framework applications under Mono?

I'm trying to build a .NET project on Mono.
efulmer:[~/projects/MyApp]$ msbuild MyApp.csproj
Microsoft (R) Build Engine version 15.3.0.0 ( Mon Aug 14 21:03:24 UTC 2017) for Mono
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 10/11/2017 3:46:23 PM.
Project "/home/efulmer/projects/MyApp/MyApp.csproj" on node 1 (default targets).
/home/efulmer/projects/MyApp/MyApp.csproj(161,3): error MSB4019: The imported project "/usr/lib/mono/msbuild/15.0/bin/Microsoft.CompactFramework.CSharp.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
Done Building Project "/home/efulmer/projects/MyApp/MyApp.csproj" (default targets) -- FAILED.
Build FAILED.
"/home/efulmer/projects/MyApp/MyApp.csproj" (default target) (1) ->
/home/efulmer/projects/MyApp/MyApp.csproj(161,3): error MSB4019: The imported project "/usr/lib/mono/msbuild/15.0/bin/Microsoft.CompactFramework.CSharp.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:00.14
The line in question is <Import Project="$(MSBuildBinPath)/Microsoft.CompactFramework.CSharp.targets" />
The underlying problem is fairly obvious to me after some searching (missing .NET Compact Framework) but I'm not sure how to solve it, as I installed mono-complete. But I don't know how to solve it. Help appreciated!

You may have a problem with case sensitivity. I had a similar problem with a program not finding Microsoft.CSHARP.Targets
It turns out that MSBuild provides a file called Microsoft.CSharp.targets
I created a symlink from Microsoft.CSHARP.Targets to Microsoft.CSharp.targets and that worked around the problem.

Does Coverity support xbuild (mono)?

I've a C# project: https://github.com/Pro/dkim-exchange
It uses Travis CI: https://travis-ci.org/Pro/dkim-exchange
Travis successfully builds my project.
I wanted to set up Coverity to do automatic code quality measurements. For this I configured my .travis.yml as follows:
language: objective-c
env:
global:
- EnableNuGetPackageRestore=true
# The next declaration is the encrypted COVERITY_SCAN_TOKEN, created
# via the "travis encrypt" command using the project repo's public key
- secure: "kC7O0CWm9h4g+tzCwhIZEGwcdiLrb1/1PijeOKGbIWGuWS7cIksAkj2tRNMgtxxcE9CFQr8W7xDv2YzflCIlqN1nGkFjbyD4CrNg6+V1j0fZjPOQ6ssdBBVPrfrvecsAUJ0/48Tqa9VTkEpZSlwOF/VS1sO2ob36FVyWjtxvG9s="
matrix:
- MONO_VERSION="3.10.0"
install:
# Fetch Mono
- wget "http://download.mono-project.com/archive/${MONO_VERSION}/macos-10-x86/MonoFramework-MDK-${MONO_VERSION}.macos10.xamarin.x86.pkg"
- sudo installer -pkg "MonoFramework-MDK-${MONO_VERSION}.macos10.xamarin.x86.pkg" -target /
script:
- xbuild travis.proj
addons:
coverity_scan:
project:
name: "Pro/dkim-exchange"
description: "Build submitted via Travis CI"
notification_email: mail#example.com
build_command_prepend: "xbuild /t:CleanAll travis.proj"
build_command: "xbuild /t:Build travis.proj"
branch_pattern: coverity_scan
If I execute the coverity build commands as indicated here (using msbuild): https://scan.coverity.com/download?tab=csharp the uploaded archive is analyzed correctly, but in combination with travis, the coverity analysis fails (see e.g. this build log: https://travis-ci.org/Pro/dkim-exchange/builds/42295611).
There's this warning:
[WARNING] No files were emitted. This may be due to a problem with your configuration
or because no files were actually compiled by your build command.
Please make sure you have configured the compilers actually used in the compilation.
I think this may be related to xbuild from Mono. Unfortunately Dr. Google didn't find anythin about Coverity+xbuild. Does Coverity support xbuild? If yes, how can I correctly setup the project?

When it comes to C#, Coverity actually only supports msbuild.
You can find some more official information about this in the following
http://www.coverity.com/library/pdf/CoverityStaticAnalysis.pdf
https://communities.coverity.com/message/6251#6251
The last link explicitly states
Our C# analysis only supports the Visual Studio C# compilers
So, no xbuild support as of now.
Update:
When you download the Coverity build tool, the doc/en/help/cov-build.txt explicitly states the following:
C# build capture is only supported on Windows.

Some confusions about Command Line Compiler and MSBuild

C# CSC.exe
If we give it a C# file, a .CS , is it able to compile it and say for example a ";" is missing at line 12 of your code? In a form that later in my program - which is Java RCP app, I can show those compile errors in a Spreadsheet
How about MSBuild? Is that able to show compile errors same as my previous example?

Think of MSBuild as a glorified make or something more like ANT - it is a language for describing compilation/build tasks. When you use MSBuild for building your c# program, you are actually using csc.exe for the compilation part.

Say this is your code (program.cs):
namespace MyCustomBuild
{
class Program
{
static void Main(string[] args)
{
System.Console.WriteLine("Hello World")
}
}
}
You can call csc program.cs and receive the following output
Microsoft (R) Visual C# 2010 Compiler version 4.0.30319.1
Copyright (C) Microsoft Corporation. All rights reserved.
program.cs(7,52): error CS1002: ; expected
Alternatively you can use msbuild to achieve the exact same result! Here is the content of build.msbuild
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="Default">
<Csc Sources="program.cs"/>
</Target>
</Project>
You can then call your msbuild file with varying levels of verbosity, as shown.
msbuild build.msbuild /verbosity:quiet and msbuild build.msbuild /verbosity:minimal
Microsoft (R) Build Engine Version 4.0.30319.1
[Microsoft .NET Framework, Version 4.0.30319.269]
Copyright (C) Microsoft Corporation 2007. All rights reserved.
program.cs(7,52): error CS1002: ; expected [<filePath>\build.msbuild]
msbuild build.msbuild /verbosity:normal:
Microsoft (R) Build Engine Version 4.0.30319.1
[Microsoft .NET Framework, Version 4.0.30319.269]
Copyright (C) Microsoft Corporation 2007. All rights reserved.
Build started 6/6/2012 12:13:00 PM.
Project "<filePath>\build.msbuild" on node 1 (default targets).
Default:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Csc.exe /out:program.exe program.cs
program.cs(7,52): error CS1002: ; expected [<filePath>\build.msbuild]
Done Building Project "<filePath>\build.msbuild" (default targets) -- FAILED.
Build FAILED.
"<filePath>\build.msbuild" (default target) (1) ->
(Default target) ->
program.cs(7,52): error CS1002: ; expected ["<filePath>\build.msbuild]
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:00.28
The remaining two verbosity levels are detailed and diagnostic and they present even more information if you want it. I'm not sure how much information you want for your spreadsheet, but hopefully one of these works for you.