Recently I was debugging very long build times of one of my company's solutions. When I cranked up the build output to diagnostic level, I noticed a lot of msbuild messages saying:
but its name "Assemlbly.Core, Version=220.127.116.11, Culture=neutral, PublicKeyToken=null"
didn't match the expected name "Assembly.Core, Version=18.104.22.168, Culture=neutral, PublicKeyToken=null
I'm not sure if this is causing my long build times, but it got me wondering if there's actually a hidden error (or warning) here? The solution builds successfully and, when
Some.Assembly.Name.dll is referenced at runtime via version
22.214.171.124 there appears to be no issue.
Some background - the large solution references everything via Nuget packages. It seems that this error is happening if the reference chain looks like this:
- Assembly.Core.dll version
- Assembly.B.dll version
- B also references Assembly.Core at version
126.96.36.199(specific version defaulted to
True in project properties)
This happens a lot in my main solution, which uses Dapper for database connectivity, and also references several other internal DLLs that also use Dapper, but may not be using (or require) the latest and greatest Dapper release. The nuspec for Assembly.B in this scenario simply indicates a dependency on
Assembly.Core.dll >= 188.8.131.52
Does anyone know if this warning is actually causing a problem, or potentially increasing build times while msbuild searches (unnecessarily) for the specific versions of the assemblies? Is there a way to suppress the messages? It seems that you can't tell Nuget to set the
SpecificVersion property to
False when the assemblies are added/updated, so I'm curious if others have run into this.