Using the binary log to find the source of a .NET dependency

 
 
  • Gérald Barré

Understanding where a dependency comes from can be tedious. This is especially true when you have a large project with many dependencies. Recently, .NET brings a new tool dotnet nuget why to help you understand why a package is installed in your project. However, there is a better way to do it, and it doesn't requires a recent SDK.

dotnet nuget why can explain why a package is included in your project:

However, it works only with the latest SDK. Also, it only works with package names. What if you want to know which package provide a specific dll that you see in the build output?

When you restore packages, NuGet writes a file called project.assets.json in the obj folder. This file contains all the information about the packages that are used in the project. You can use this file to find out which package provides a specific dll. This is a json file and it can be very large. A better way to explore this file is to build the project first using the binary logger. This will produce a .binlog file that you can use to explore using a wonderful tool named MSBuild Structured Log Viewer.

The binlog includes the project.assets.json file. MSBuild Structured Log Viewer provides a way to query the content of this file.

First, you need to build the project using the binary logger:

Shell
dotnet build /bl

Then, you can open the .binlog file using MSBuild Structured Log Viewer and search for the NuGet package or file you are interested in:

$nuget project(.csproj) analyzers.dll

MSBuild Structured Log Viewer - Search NuGet packages and filesMSBuild Structured Log Viewer - Search NuGet packages and files

The search syntax is powerful, read more at MSBuildStructuredLog Wiki - Search Syntax. In a nutshell, you can search for package name, package files, or package version.

Do you have a question or a suggestion about this post? Contact me!

Follow me:
Enjoy this blog?Buy Me A Coffee💖 Sponsor on GitHub