Building with MSBuild produced an error or warning
Run MSBuild with (d)etailed verbose mode and capture the output to a file:
1
| msbuild someproject.csproj /t:Clean;Build;Transfer /p:OutputPath=bin\autobuild;BuildNumber=-1;Configuration=Debug /v:d >build.txt |
Open build.txt and search for the MSBxxxx error or warning code. For example:
1
2
| Consider app.config remapping of assembly "DotNetOpenAuth.AspNet, Culture=neutral, PublicKeyToken=2780ccd10d57b246" from Version "4.0.0.0" [] to Version "4.1.0.0" [C:\somedir\bin\DotNetOpenAuth.AspNet.dll] to solve conflict and get rid of warning.
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets(1605,5): warning MSB3247: Found conflicts between different versions of the same dependent assembly. |
If it doesn’t already exist, add an App.config file with the following content:
1
2
3
4
5
6
7
8
9
10
11
| <?xml version="1.0" encoding="utf-8" ?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="DotNetOpenAuth.AspNet" publicKeyToken="2780ccd10d57b246" />
<bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.1.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration> |
Also change your .csproj to include the App.config file:
1
2
3
| <ItemGroup>
<None Include="App.config" />
</ItemGroup> |
A few useful additions.
This fix applies to classic .NET Framework, not .NET Core / .NET 5+. Binding redirects in App.config are a .NET Framework concept. Modern .NET (Core 3.x, 5, 6, 7, 8, 9, …) resolves assembly versions through *.deps.json and unifies them automatically — you don’t write binding redirects, and MSB3247 generally doesn’t show up the same way. If your project is <Project Sdk=”Microsoft.NET.Sdk”> rather than the legacy XML format, you’re on modern .NET and this post doesn’t apply. 🧭
A better way to inspect a build than reading build.txt. Pass /bl (or -bl) to MSBuild instead of (or in addition to) /v:d:
1
| msbuild someproject.csproj /t:Build /bl |
This produces an msbuild.binlog file with the full structured build log. Open it in the free MSBuild Structured Log Viewer and you get a navigable tree of every target, task, and property, with full search — a vastly better experience than grepping through a text file. /v:diag is the next step up in plain-text verbosity if you don’t want a binlog (and is what the docs call “diagnostic” level).
Two other MSBuild errors that come up a lot.
MSB3644 — “Reference assemblies for .NETFramework,Version=vX.X were not found”. Classic on a fresh build agent. The targeting pack for the .NET Framework version your project asks for isn’t installed. Two fixes: install the matching .NET Framework Targeting Pack via the Visual Studio Installer (Individual components → “.NET Framework X.X targeting pack”), or downgrade <TargetFrameworkVersion> in your .csproj to a version that is installed.
MSB4018 — “The X task failed unexpectedly”. The MSBuild equivalent of “something blew up, here’s the stack trace”. Usually one of: a custom task that crashed, an SDK version mismatch (your global.json pins an SDK that isn’t on the machine), or a corrupted obj/ folder from an interrupted build. The standard checklist: delete bin/ and obj/, run dotnet restore (or nuget restore for legacy), confirm dotnet –version matches what global.json demands, then rebuild. If it still fails, the binlog from the previous tip will show you which task threw — that’s nearly always the real clue. 🛠️