-
-
Notifications
You must be signed in to change notification settings - Fork 198
Investigating Assembly version issues during build and at runtime
http://msbuildlog.com - run the build with /bl and inspect the resulting .binlog in the Viewer. Examples of search strings to use in the Viewer:
Copying System.Net.Http.dllSystem.Net.Http under(ResolveReferences)There was a conflict
Keep in mind that the .binlog files contain confidential information such as the user's Environment and the source of all project and targets files. If IP is an issue, tell them to not share the binlogs (http://msbuildlog.com/#security)
https://github.com/Microsoft/msbuild/blob/master/documentation/wiki/ResolveAssemblyReference.md
Figure out where RAR is resolving the .dlls from, what it is unified to and which version gets copied to output, if any.
Search for $task ResolveAssemblyReference and inspect the Results node. Sort node's Children alphabetically by right-clicking on a node.
Use the lbi.exe tool in the repo root: C:\yourrepo> lbi.exe System.Net.Http.dll You can download it from: https://github.com/KirillOsenkov/CodeCleanupTools/releases/tag/lbi-2018-8-31 It will print the versions of all System.Net.Http.dll files in the repo, recursively. You can then investigate where they’re being copied from.
Use the fuslogvw.exe tool (Fusion logger) to diagnose where assemblies are loaded from at runtime and which versions.
Pay attention to the value of the AssemblySearchPaths MSBuild property. It determines in what order RAR will look for your assembly and where.