Working with Large Types

Some .NET types are enormous. God classes with hundreds of methods, auto-generated code from ORMs and serializers, or WinForms designers with thousands of lines of layout code — these can easily exceed the default output limit when decompiled. mcilspy v0.5.0 introduced output truncation and method-level decompilation to handle this.

How Truncation Works

The decompile_assembly tool has a max_output_chars parameter that defaults to 100,000 characters. When the decompiled output exceeds this limit, mcilspy:

1. Saves the full output to a temporary file on disk.
2. Returns a truncated preview with the first portion of the code.
3. Includes the temp file path so you can read the rest.
4. Lists recovery options for getting the complete content.

The truncation message looks like this:

Output truncated (245,000 chars exceeded 100,000 char limit)
Full output saved to: /tmp/mcilspy_full_output_abc123.cs

Note

Truncation protects MCP clients from choking on massive responses. The full output is always preserved on disk — nothing is lost.

Extracting Specific Methods

When you know which method you need, decompile_method extracts just that method from a type without returning the rest of the class. This is the primary tool for working with large types.

"Decompile the ProcessPayment method from MyApp.OrderService"

The tool decompiles the full type internally, then extracts and returns only the named method. If multiple overloads exist, all of them are returned.

1. Find the method name — Use search_methods to locate methods by name pattern within a specific type:

   "Search for methods in MyApp.dll filtered to type OrderService"

2. Extract the method — Call decompile_method with the assembly path, fully qualified type name, and method name:

   "Decompile the method ProcessPayment from type MyApp.Services.OrderService in MyApp.dll"

3. Choose your output format — By default, decompile_method returns IL bytecode, which is the most reliable format for extraction. Set show_il_code to false for C# output instead.

IL vs C# Extraction

The decompile_method tool defaults to IL output (show_il_code: true) because IL has standard ECMA-335 delimiters that make method boundaries unambiguous:

.method public hidebysig instance void ProcessPayment(...) cil managed
{
    // method body
} // end of method OrderService::ProcessPayment

C# extraction uses signature matching with brace-depth counting, which works well but can occasionally trip on unusual formatting. If C# extraction misses a method, try IL mode first.

Adjusting the Truncation Limit

You can control truncation per-call:

• Increase the limit — Set max_output_chars to a larger value (e.g., 500000) when your client can handle more data.
• Disable truncation — Set max_output_chars to 0 to return the full output regardless of size. Use with caution on very large types.
• Decrease the limit — Set a smaller value if you only need to see the beginning of a file to orient yourself.

"Decompile MyApp.dll with max_output_chars set to 0"

Recovery Options After Truncation

When output is truncated, you have several paths forward:

Approach	When to use
Read the temp file directly	You need the complete output and your client can handle file reads
Use decompile_method	You only need specific methods from the type
Increase max_output_chars	The output is just slightly over the limit
Use create_project with output_dir	You want all files saved to disk and organized by namespace

Tip

For assemblies where you need everything on disk rather than inline, use decompile_assembly with an output_dir. This writes files directly to disk and returns just the output path, bypassing truncation entirely.