icsharpcode/ILSpy

How to deal with assembly binding redirects?

Open

#1508 opened on May 4, 2019

View on GitHub
 (1 comment) (0 reactions) (0 assignees)C# (25,162 stars) (3,645 forks)batch import
EnhancementHelp Wanted

Description

Larger applications consisting of multiple assemblies these days usually have binding redirects in place. As far as I can tell this leads to ILSpy not being able to resolve references (or sometimes pulling in duplicate assemblies with different versions from the GAC) and generally a lower quality of the decompiled code.

Am I missing anything in how to deal with assembly-setups requiring binding redirects? Otherwise I think its time to consider this as a new feature, going forward with nuget based packaging I think redirected bindings will become much more common than they were in the past.

Contributor guide

Tech stack
csharp
Domain
desktoptooling
Issue type
feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
4
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
over 1 week
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
needs investigation
Prerequisites
C# knowledgeUnderstanding of .NET assembly binding
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
25
Research direction
Investigate how ILSpy currently resolves assemblies and identify where binding redirects from app.config or runtime configuration are ignored. Look at existing code for assembly loading in ILSpy (e.g., AssemblyList or AssemblyResolver classes). Consider how to incorporate binding redirect logic from NuGet packages or application configuration files.