Evaluate dnlib upgrade from 3.6.0 to 4.x

[mcpolo99]

Goal

Evaluate upgrading dnlib from 3.5.0 to the latest 4.x release. dnlib is the core .NET metadata library that ConfuserEx depends on for all assembly reading, writing, and manipulation.

Why

• dnlib 3.5.0 was released in 2022 — there may be bug fixes, performance improvements, and better .NET 6/8/10 support in 4.x
• The .NET 10 retarget (Retarget GUI and CLI to .NET 10 #53) may benefit from a newer dnlib but should NOT be blocked by it
• API changes between 3.x and 4.x need evaluation before upgrading

What Needs Investigation

1. Changelog review — what changed between 3.5.0 and latest 4.x?
2. Breaking API changes — any renamed/removed/changed methods that ConfuserEx uses?
3. Our custom extensions — DnlibUtils.cs has extension methods on dnlib types. Do they still compile?
4. Resolve/ResolveThrow behavior — any changes to the resolution API we heavily depend on?
5. ModuleWriter changes — anti-tamper and packer hook into writer events. Any event API changes?
6. AssemblyResolver changes — our ConfuserAssemblyResolver wraps dnlib's resolver. Any interface changes?
7. netstandard2.0 compatibility — does dnlib 4.x still target netstandard2.0?

Approach

• Do NOT combine with Retarget GUI and CLI to .NET 10 #53 (.NET 10 retarget) — keep it separate to isolate risk
• Evaluate first, implement only if API changes are manageable
• Full test suite must pass after upgrade

Related Issues

• Retarget GUI and CLI to .NET 10 #53 — .NET 10 retarget (benefits from but doesn't depend on this)

[jeremy-visionaid]

In the meantime we could update to 3.6.0 which has some bug fixes:
#77

[mcpolo99]

merged #77

[github-actions]

Lint Results

✅ All checks passed

Check	Result
Whitespace (indentation, line endings)	✅
Style (IDE rules, naming, var usage)	✅
Analyzers (CA*, RCS* rules)	✅

[mcpolo99]

Evaluation: can dnlib 4.5 improvements be leveraged further?

Beyond the straight upgrade (PR #87), I evaluated whether dnlib 4.x features could improve ConfuserEx itself. Summary: 4.5 is a solid low-risk maintenance upgrade, but it does not unlock new obfuscation capabilities. Details below — testing beat speculation on several of these.

1. Packer + .NET 6+ entry point — ❌ no win

Hypothesised that v4.5's "ModuleWriter no longer ignores Cor20HeaderOptions.EntryPoint" could improve the compressor packer. Evidence killed it:

• We never set Cor20HeaderOptions.EntryPoint — only .Flags (to clear ILOnly for mixed-mode). The v4.5 fix doesn't touch our code path.
• The known ".NET 6+" limitation is the native apphost — the .exe is a native host stub, not a managed assembly, so no dnlib version can read it. Unrelated to entry-point writing.
• Packer works correctly on managed input (CompressorWithResx: 12 tests green on 4.5).

2. AllowByRefLike generic parameters (v4.5) — ✅ free / non-issue

RenamePhase.RenameGenericParameters only assigns param.Name; it never touches GenericParam.Flags/attributes. So ref-struct generic constraints (where T : allows ref struct) round-trip untouched on both 3.6 and 4.5. Handled correctly for free — no action needed.

3. New TryGet*Sig / TryGetTypeDef family — ⚠️ low value

Our signature-access patterns (e.g. sig as GenericInstSig) are already null-safe. TryGet*Sig only adds modifier/pinned-sig unwrapping — a niche edge case. The genuine crash surface (throwing ResolveThrow calls, addressed in #84) uses the existing non-throwing ResolveTypeDef(), not this new family. A ~12-file refactor for marginal robustness — not worth it.

4. Performance (v4.0 type-name, v4.2 custom-attribute lookup) — 📊 modest, measured

A/B benchmark, obfuscating a 362 KB assembly with rename + ctrl flow + constants (best of warm runs):

dnlib	Wall-clock
3.6.0	~663 ms (573–720, noisy)
4.5.0	~565 ms (561–570)

~10–15% faster, though variance is high on this size. The optimizations are real but incremental; the benefit grows on attribute-heavy / larger assemblies. No code changes required — it's a free upgrade benefit.

Conclusion

Ship the 3.6 → 4.5 upgrade (#87) on its own merits: bug fixes (PDB column sizes, SigComparer regression, ECMA ExportedType sorting), modern-.NET metadata recognition, and ~10% perf. No compelling follow-up work — the "better uses" opportunities evaporated under evidence. Validated by the full 144-test suite restored in #84.

[mcpolo99]

Resolved by #87, squash-merged into develop as 9844573.

Upgraded dnlib 3.6.0 → 4.5.0. Only one breaking API change affected us (IChunk.CalculateAlignment, implemented on the two AntiTamper JIT chunks). Full 144-test suite green.

The evaluation of further leverage found no major follow-up work, but two low-risk captures shipped in the same PR:

• HasAttribute now routes through dnlib's IsDefined (the by-full-name lookup dnlib 4.2 optimized)
• A regression test locking in that obfuscation preserves the allows ref struct generic constraint (AllowByRefLike) — 145 tests now

Will close automatically on GitHub once develop → main ships.