.NET DLL Compare

Compare an older and newer managed .NET assembly locally. Standard mode reports assembly, framework, namespace, type, member, public API, reference, resource, attribute, reconstructed C# stub, IL, and breaking-change differences. Dynamics mode adds heuristic plugin, workflow, SDK-reference, API-compatibility, and deployment-risk signals.

How to Use the .NET DLL Compare

Compare two managed assemblies locally—Standard for general libraries, Dynamics mode for extra CRM/Dataverse heuristics.

  1. Choose Standard DLL Compare or Dynamics CRM / Dataverse DLL Compare.
  2. Drop the older baseline on the left and the newer candidate on the right (.dll / .exe / .winmd, ≤ 40 MB each).
  3. Confirm parsed assembly names, versions, target frameworks, sizes, type counts, and reference counts.
  4. Select Compare DLLs, then review overview tabs; in Dynamics mode also read the CRM summary.
  5. Copy or download the short report and investigate every breaking or high-risk signal before release.

How comparison works

The browser reads managed metadata and available method bodies, diffs identity and API surfaces, reconstructs signature stubs, and disassembles IL when possible. Dynamics mode layers pattern-based CRM analysis onto that same report.

Interpreting results

  • Removed or changed public members deserve compatibility review even when counts look small.
  • C# panels are stubs; IL panels show low-level instructions when bodies exist.
  • Dynamics risk, SDK bumps, and plugin lists are signals—verify against registrations and deployment plans.

Example scenarios

Standard: bump MyLib 1.0.0 → 1.1.0 and confirm whether a removed public method is flagged breaking. Dynamics: compare Contoso.Plugins.dll versions and inspect whether Execute signatures, SDK references, or plugin types changed before importing a solution.

Mistakes and limitations

  • Reversing baseline/candidate flips added vs removed.
  • Static comparison cannot prove runtime behavior, config, or external dependency health.
  • Only the first 12 differing types appear in the C# / IL panel.

Privacy note

Assembly bytes never leave the browser for a ToolsLibrary upload. DLLs may contain proprietary names, strings, and resources—only compare files you are authorized to inspect and protect downloaded reports.

FAQ

Are my DLLs uploaded to a server?

No. Selected assemblies are read, parsed, and compared in your browser. Each side accepts one .dll, .exe, or .winmd file up to 40 MB.

Is the C# panel a full decompiler?

No. It reconstructs C#-like stubs from metadata signatures and can show disassembled IL for method bodies when present. It is not ILSpy/dnSpy-quality decompilation or Roslyn recompile.

What does Dynamics mode add?

On top of the standard metadata/API/IL comparison, Dynamics CRM / Dataverse mode adds heuristic signals for plugin classes, Execute changes, workflow activities, custom APIs, SDK references, and a deployment-risk summary. Treat them as review aids, not deployment approval.

How should I read the Breaking count?

It screens likely compatibility issues such as removed or changed public surface area. It is not a complete semantic compatibility proof and cannot see reflection-only callers or configuration-driven behavior.

Why are only some types shown in C# / IL?

The UI lists the first 12 differing types in the C# / IL view to keep the report readable. Use overview and other tabs for the broader diff, and inspect remaining types with your desktop tooling if needed.

What happens if I swap baseline and candidate?

Added vs removed interpretations reverse. Keep the older assembly on the left (baseline) and the newer on the right (candidate) so the report direction matches your upgrade story.

Which binaries are unsupported or incomplete?

Native-only DLLs, many mixed-mode scenarios, obfuscated assemblies, malformed metadata, and behavior created only at runtime may fail to parse or compare incompletely. Prefer managed assemblies you are authorized to inspect.

Does High deployment risk block a release?

No. Risk is a heuristic summary for human review. Always validate plugin steps, images, isolation mode, SDK versions, and solution packaging in your ALM process before production.