Confirm the format
Run the free VBScanner on the folder. It reads the file headers and tells you what built each EXE, DLL or OCX and whether it is P-Code, native or IL.
A .NET assembly keeps its metadata by design — every type, method, field and property is named in the file — so the question is not whether it can be decompiled but how readable the result is. Our .NET decompiler emits both C# and VB.NET from the same assembly, alongside the raw IL, and packages them as a Visual Studio solution. It earns its place for VB6-era projects that were upgraded to VB.NET and now sit on the same shelf as the VB6 originals.
The CLR header points to the metadata block, signed BSJB, and its streams: the
compressed table stream, #Strings, #US for user strings,
#GUID and #Blob. The engine parses all 45 metadata tables, reads each
method body — tiny or fat header, local signature — and decodes the IL. From there it emits typed
declarations and runs a structuring pass over the control flow: if / else,
while, do-while, foreach, switch,
try / catch / finally and filters, with a labelled
goto only where the flow genuinely cannot be structured.
Types, fields, methods, parameters and real Property blocks in both languages — 94 raw accessor methods collapse back into 47 properties on our benchmark — plus the complete IL listing for reference.
.sln, a C# project and a VB.NET project, one source file per class, with AssemblyRef entries turned into references and embedded resources extracted byte-identical to the originals.
P/Invoke tables become real Declare / [DllImport] statements, constants keep their values, multi-dimensional arrays and AddHandler / RemoveHandler event wiring come back, and integer versus floating division is proven from the IL rather than guessed.
| prjMapEditor — VS 2003, .NET 1.1, upgraded from VB6, 160 methods | Result |
|---|---|
| Methods and properties reconstructed | 66 + 47 = all 160, 0 failures |
| VB.NET compile errors on the emitted source | 215+ → 7 |
| Integer divisions recognised (source has 20) | 21, 0 floating false positives |
| Embedded resources | byte-identical to the originals |
| Output size | 2,415 lines of VB.NET · 100 KB of C# · 274 KB of IL |
Local variable names live in the PDB, not the assembly, so locals come back as
V_0, V_1 unless you still have the PDB. For loops are
currently emitted as the while loops they compile to, and the C# output needs more
clean-up than the VB.NET output because C# has no Option Strict Off. Obfuscated
assemblies are assessed case by case. If your only problem is a modern .NET assembly, one of the
excellent free .NET decompilers may serve you well; where ours pays off is a mixed shelf of VB6
and VB.NET programs handled with one tool and one report.
Run the free VBScanner on the folder. It reads the file headers and tells you what built each EXE, DLL or OCX and whether it is P-Code, native or IL.
License the software — $299 for one computer or $1,499 for your whole organization with the command line — and run it on your own machine. Nothing leaves your network.
Request a free evaluation. We examine the binary, tell you exactly what comes back, and quote a fixed price and timeline. Hand-finishing of anything the engine marks is included.
Both, from the same assembly, in one Visual Studio solution. Maintain whichever your team prefers and keep the IL listing for reference.
The VB.NET output of our benchmark compiles with 7 remaining errors out of 160 methods, all of the same two kinds; C# needs more attention. Expect a clean-up pass, not a rewrite.
Metadata that has been renamed decompiles to renamed code; control-flow obfuscation is assessed during the free evaluation.
The evaluation is free and tells you exactly what your binary yields before you spend anything. Or license the decompiler and run it in-house today.