So far, I’ve identified that the version of
System.Reflection found in the NuGet package is version 126.96.36.199 and the version in the global assembly cache is version 188.8.131.52 - so where is the version that the build process is choosing?
Returning to the build log, I used the structured log viewer to search for
system.reflection.dll under(dfcmd) and worked my way through all 223 occurrences.
As a part of the command line provided to
csc.exe (the C# compiler itself), I found this option:
(Note that I’ve formatted the path with some linebreaks.)
Using the same PowerShell command as before, I checked the actual version of this assembly:
That’s exactly the assembly I wanted - and the clue that I needed to solve the problem.
Having the assembly file
System.Reflection.dll omitted from the build output directory is totally correct - because it’s a part of the installed .NET runtime, and doesn’t need to be separately deployed.
Since this is the case, I conjectured that I didn’t need to separately reference it from the
dfcmd project - and so I removed both the package reference from the
.csproj file, and the related binding redirects from the
After a full rebuild, I ran the same command as before:
So what are the lessons here?
I’m reminded that the version of a NuGet package doesn’t necessarily predict the versions of the assemblies found inside.
And, sometimes, the assembly binding redirects introduced into
app.config are the problem, not the solution.