Home Unmatched Version References with NuGet Packages
 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: Considered "bin\Debug\Assembly.Core.dll", but its name "Assemlbly.Core, Version=1.0.0.4, Culture=neutral, PublicKeyToken=null" didn't match the expected name "Assembly.Core, Version=1.0.0.1, 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 1.0.0.4 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: Main.Application.exe Assembly.Core.dll version 1.0.0.4 Assembly.B.dll version 2.0.0.0 B also references Assembly.Core at version 1.0.0.1(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 >= 1.0.0.1 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.