Understanding build log for "Found conflicts between different versions of "Microsoft.WindowsAzure.Storage" that could not be resolved."

Question

The build log from Visual Studio 2017 (15.5.4) has left me stumped on how to get rid of the warning

Found conflicts between different versions of "Microsoft.WindowsAzure.Storage" that could not be resolved. These reference conflicts are listed in the build log when log verbosity is set to detailed. Animals.Swine.Functions C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets

There was a conflict between "Microsoft.WindowsAzure.Storage, Version=7.2.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" and "Microsoft.WindowsAzure.Storage, Version=8.1.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35".
    "Microsoft.WindowsAzure.Storage, Version=7.2.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" was chosen because it was primary and "Microsoft.WindowsAzure.Storage, Version=8.1.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" was not.
    References which depend on "Microsoft.WindowsAzure.Storage, Version=7.2.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" [D:\Repos\Animals\src\Animals.Swine\packages\WindowsAzure.Storage.7.2.1\lib\net40\Microsoft.WindowsAzure.Storage.dll].
        D:\Repos\Animals\src\Animals.Swine\packages\WindowsAzure.Storage.7.2.1\lib\net40\Microsoft.WindowsAzure.Storage.dll
          Project file item includes which caused reference "D:\Repos\Animals\src\Animals.Swine\packages\WindowsAzure.Storage.7.2.1\lib\net40\Microsoft.WindowsAzure.Storage.dll".
            Microsoft.WindowsAzure.Storage, Version=7.2.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL
    References which depend on "Microsoft.WindowsAzure.Storage, Version=8.1.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" [].
        D:\Repos\Animals\src\Animals.Common\Animals.Common.Functions\bin\Debug\net461\bin\Animals.Common.Functions.dll
          Project file item includes which caused reference "D:\Repos\Animals\src\Animals.Common\Animals.Common.Functions\bin\Debug\net461\bin\Animals.Common.Functions.dll".
            D:\Repos\Animals\src\Animals.Common\Animals.Common.Functions\bin\Debug\net461\bin\Animals.Common.Functions.dll
        D:\Repos\Animals\src\packages\Microsoft.Azure.WebJobs.2.1.0\lib\net45\Microsoft.Azure.WebJobs.Host.dll
          Project file item includes which caused reference "D:\Repos\Animals\src\packages\Microsoft.Azure.WebJobs.2.1.0\lib\net45\Microsoft.Azure.WebJobs.Host.dll".
            Microsoft.Azure.WebJobs.Host, Version=2.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL
            Microsoft.Azure.WebJobs.Extensions, Version=2.0.0.0, Culture=neutral, processorArchitecture=MSIL
        D:\Repos\Animals\src\Animals.Common\Animals.Common\bin\Debug\net45\Animals.Common.dll
          Project file item includes which caused reference "D:\Repos\Animals\src\Animals.Common\Animals.Common\bin\Debug\net45\Animals.Common.dll".
            D:\Repos\Animals\src\Animals.Swine\Animals.Swine\bin\Debug\Animals.Swine.dll
            D:\Repos\Animals\src\Animals.Common\Animals.Common\bin\Debug\net45\Animals.Common.dll
        D:\Repos\Animals\src\Animals.Swine\packages\Microsoft.Azure.WebJobs.Extensions.2.0.0\lib\net45\Microsoft.Azure.WebJobs.Extensions.dll
          Project file item includes which caused reference "D:\Repos\Animals\src\Animals.Swine\packages\Microsoft.Azure.WebJobs.Extensions.2.0.0\lib\net45\Microsoft.Azure.WebJobs.Extensions.dll".
            Microsoft.Azure.WebJobs.Extensions, Version=2.0.0.0, Culture=neutral, processorArchitecture=MSIL

If we walk through the references that reportedly use Storage 8.1.1.0, we see that the first, third and last ones look to reference itself. Why does it think that? What does that even mean?

    D:\Repos\Animals\src\Animals.Common\Animals.Common.Functions\bin\Debug\net461\bin\Animals.Common.Functions.dll
      Project file item includes which caused reference "D:\Repos\Animals\src\Animals.Common\Animals.Common.Functions\bin\Debug\net461\bin\Animals.Common.Functions.dll".
        D:\Repos\Animals\src\Animals.Common\Animals.Common.Functions\bin\Debug\net461\bin\Animals.Common.Functions.dll
    ...
    D:\Repos\Animals\src\Animals.Common\Animals.Common\bin\Debug\net45\Animals.Common.dll
      Project file item includes which caused reference "D:\Repos\Animals\src\Animals.Common\Animals.Common\bin\Debug\net45\Animals.Common.dll".
        D:\Repos\Animals\src\Animals.Swine\Animals.Swine\bin\Debug\Animals.Swine.dll
        D:\Repos\Animals\src\Animals.Common\Animals.Common\bin\Debug\net45\Animals.Common.dll
    D:\Repos\Animals\src\Animals.Swine\packages\Microsoft.Azure.WebJobs.Extensions.2.0.0\lib\net45\Microsoft.Azure.WebJobs.Extensions.dll
      Project file item includes which caused reference "D:\Repos\Animals\src\Animals.Swine\packages\Microsoft.Azure.WebJobs.Extensions.2.0.0\lib\net45\Microsoft.Azure.WebJobs.Extensions.dll".
        Microsoft.Azure.WebJobs.Extensions, Version=2.0.0.0, Culture=neutral, processorArchitecture=MSIL

The second one seems like a better place to check and discuss:

    D:\Repos\Animals\src\packages\Microsoft.Azure.WebJobs.2.1.0\lib\net45\Microsoft.Azure.WebJobs.Host.dll
      Project file item includes which caused reference "D:\Repos\Animals\src\packages\Microsoft.Azure.WebJobs.2.1.0\lib\net45\Microsoft.Azure.WebJobs.Host.dll".
        Microsoft.Azure.WebJobs.Host, Version=2.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL
        Microsoft.Azure.WebJobs.Extensions, Version=2.0.0.0, Culture=neutral, processorArchitecture=MSIL

So if I'm reading this right, Microsoft.Azure.WebJobs.Host, Version=2.1.0.0 and Microsoft.Azure.WebJobs.Extensions, Version=2.0.0.0 should both have references to Microsoft.WindowsAzure.Storage, Version=8.1.1.0. However, if we look at the Nuget dependencies, WebJobs references 7.2.1.0 and WebJobs.Extensions just references back to [WebJobs].

I don't see anything referencing 8.1.1.0! Storage isn't referenced directly by any project and I see no indirect references.

I've run AsmSpy on "D:\Repos\Animals\src\Animals.Swine\Animals.Swine.Functions\bin\", but it doesn't even show a conflict for Storage.

How can I figure out where the Storage 8.1.1.0 reference is coming from?

UPDATE: I did a text search and found that a binding redirect was set up with "8.1.1.0" as the newVersion. I changed that to "7.2.1.0" and the warning went away. Even thought the warning is gone, I'm leaving the question open so someone can provide insight into how to read the build logs and how the logs could have pointed us in the right direction.

Answer 1

How can I figure out where the Storage 8.1.1.0 reference is coming from?

Build log can help us resolve most of the issues, but it does not resolve all the issues. It still need us to troubleshootings those issues manually. Because Visual Studio/MSBuild could not be smart to directly find the root cause of the issue.

When we meet this MSB3247/MSB3277 error, the best way to resolve this issue is turn MSBuild output log to Diagnostic (Tools->Options->Project and Solutions->Build and Run, set MSBuild project build output verbosity), then find the references which depend on Microsoft.WindowsAzure.Storage, check if there are different versions of Microsoft.WindowsAzure.Storage being referenced.

In the build log, we found that Project file item includes which caused reference Microsoft.Azure.WebJobs.2.1.0 and Microsoft.Azure.WebJobs.Extensions.2.0.0

Then check the dependencies of those two packages, none of them have reference to Microsoft.WindowsAzure.Storage, Version=8.1.1.0.

In order to confirm it, you can use the method which provided by Vladimir in the comment.

At this moment, this conflict should not come from references. Then we should check the file related to reference version, for example, app.config or web.config, find binding redirect about reference Microsoft.WindowsAzure.Storage, check if binding redirect is correct.

So sometimes we can not directly solve the problem based only on build log information, manual troubleshooting is also essential.