Reputation: 129
Say we have:
Nuget has a great functionality, which automatically detects these assembly conflicts and creates a binding redirect instructions. Nuget command Add-BindingRedirect will add such strings to test project web.config file:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="NH" publicKeyToken="aa95f207798dfdb4" culture="neutral" />
<bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
Now imagine that we have much more libraries, referrencing NH. The question is: what is the best (preferable not manual) way to identify the odd version?
Upvotes: 0
Views: 684
Reputation: 42434
To investigate binding errors you can utilize the Fusion Log Viewer.
You can configure it to log all binds which will basically give you insight in which assemblies gets loaded from where.
typical output looks like this:
=== Pre-bind state information ===
LOG: DisplayName = graphicfailtest.resources, Version=0.0.0.0, Culture=en-US, PublicKeyToken=null
(Fully-specified)
LOG: Appbase = C:\bla\graphic\cs\
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = NULL
Calling assembly : graphicfailtest, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: Processing DEVPATH.
LOG: DEVPATH is not set. Falling through to regular bind.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Post-policy reference: graphicfailtest.resources, Version=0.0.0.0, Culture=en-US, PublicKeyToken=null
LOG: Attempting download of new URL file:///C:..../graphicfailtest.resources.DLL.
LOG: All probing URLs attempted and failed.
Upvotes: 1