Fuse for .NET Developers

The fuse dotnet command is a specialized tool designed to prepare .NET codebases (C#, F#, ASP.NET Core) for Large Language Models (LLMs).

While standard file concatenation is sufficient for backups, it is inefficient for LLM context windows. C# is a verbose language, requiring significant boilerplate to satisfy the compiler. This boilerplate—while necessary for building—is often "noise" to an AI trying to understand system architecture or business logic.

Fuse reduces token count by 30-50% on typical .NET projects by intelligently stripping this noise while preserving the semantic core of your code.

---

The Philosophy: Signal-to-Noise Ratio

LLMs have finite context windows (e.g., 8k, 32k, 128k tokens). Every token spent on a license header, a standard using statement, or a closing brace is a token stolen from your actual business logic.

Fuse approaches .NET code with a specific hierarchy of value:

1. High Value (Signal): Class names, method signatures, logic bodies, functional attributes ([Route], [JsonProperty]).
2. Low Value (Noise): Namespace indentation, using statements, this. qualifiers, brace formatting.
3. Negative Value (Distraction): Generated code, binary resources, local config, debug attributes.

---

1. Smart Filtering (The "Negative Value" Filter)

Before processing a single line of code, Fuse filters the file list. The .NET template is pre-configured to aggressively exclude files that confuse LLMs or waste massive amounts of tokens.

Excluded Directories

Directory	Reason
bin/, obj/	Compiled binaries and intermediate build artifacts.
.vs/, .idea/	IDE-specific user settings and caches.
TestResults/	Verbose XML/TRX files from test runs.
node_modules/	Common in ASP.NET Core SPA templates; contains thousands of JS files.
packages/	Legacy NuGet package restore location.

Excluded File Patterns

Pattern	Description	Why it's removed
*.g.cs, *.Designer.cs	Generated Code	Contains thousands of lines of machine-generated logic (e.g., WinForms setup) that the LLM cannot modify and shouldn't analyze.
*.resx	Resource Files	XML files often containing base64 encoded images or localization strings. Extremely token-heavy.
launchSettings.json	Local Config	Contains local ports and environment variables irrelevant to the application logic.
packages.lock.json	Lock Files	Dependency trees that provide no architectural insight.
*.min.js, *.map	Web Artifacts	Minified code and source maps are unreadable and redundant if source files exist.

---

2. The Minification Pipeline

When you run fuse dotnet --all (or specific flags), the content passes through a multi-stage pipeline in CSharpMinifier.cs.

Stage 1: Comment Removal

Flag: --remove-csharp-comments Removes:

• Single-line comments: // TODO: Fix this
• Multi-line comments: /* ... */
• XML Documentation: /// <summary>...

Rationale: While comments are useful for humans, they often duplicate the code's intent. For an LLM task focused on refactoring or bug fixing, the code itself is the source of truth.

Stage 2: Preprocessor Cleanup

Flag: --remove-csharp-regions Removes:

• #region MyRegion and #endregion
• #pragma warning disable
• #nullable enable

Rationale: Regions are purely for IDE organization and break the flow of reading for an LLM.

Stage 3: Using Removal

Flag: --remove-csharp-usings Removes all using System...; statements from the top of the file.

Rationale: LLMs are excellent at inferring context. If they see StringBuilder, they know it belongs to System.Text. They do not need 20 lines of imports to understand the code.

Stage 4: Namespace Flattening (High Impact)

Flag: --remove-csharp-namespaces This is a structural transformation.

1. Removes the namespace MyProject.Services { ... } wrapper.
2. Unindents the entire file body by 4 spaces (or 1 tab).

Rationale: In a file with 100 lines of code, 4 spaces of indentation per line equals ~400 characters (~100 tokens) of pure whitespace. Flattening the structure recovers this space.

Stage 5: Aggressive Reduction

Flag: --aggressive (Included in --all) Applies heuristics to compress code density.

A. Attribute Filtering

Removes "Noise" attributes that control debugger or editor behavior, while keeping "Functional" attributes that define runtime behavior.

• Removed: [DebuggerDisplay], [Serializable], [MethodImpl], [EditorBrowsable], [GeneratedCode].
• Kept: [Route], [HttpGet], [JsonProperty], [Required], [Authorize].

B. Property Compression

Collapses verbose auto-properties into single lines.

// Before (4 lines)
public int Id
{
    get;
    set;
}

// After (1 line)
public int Id { get; set; }

C. Keyword Cleanup

Removes redundant this. qualifiers.

• this.UserService.GetAll() -> UserService.GetAll()

---

3. Before & After Example

To demonstrate the power of fuse dotnet --all, consider this realistic Service class.

Input File (Original)

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Threading.Tasks;
using Microsoft.Extensions.Logging;

namespace Fuse.Example.Services
{
    /// <summary>
    /// Manages user data processing.
    /// </summary>
    public class UserProcessor
    {
        private readonly ILogger<UserProcessor> _logger;

        public UserProcessor(ILogger<UserProcessor> logger)
        {
            _logger = logger;
        }

        [DebuggerDisplay("User {Id}: {Name}")]
        public class UserDto
        {
            public int Id
            {
                get;
                set;
            }

            public string Name
            {
                get;
                set;
            }
        }

        #region Processing Logic

        public async Task ProcessUserAsync(UserDto user)
        {
            // Validate the user
            if (user == null) throw new ArgumentNullException(nameof(user));

            _logger.LogInformation("Processing user...");

            // Simulate work
            await this.DoWorkAsync(user.Id);
        }

        #endregion

        private Task DoWorkAsync(int id)
        {
            return Task.CompletedTask;
        }
    }
}

Output File (fuse dotnet --all)

public class UserProcessor
{
    private readonly ILogger<UserProcessor> _logger;

    public UserProcessor(ILogger<UserProcessor> logger)
    {
        _logger = logger;
    }

    public class UserDto
    {
        public int Id { get; set; }
        public string Name { get; set; }
    }

    public async Task ProcessUserAsync(UserDto user)
    {
        if (user == null) throw new ArgumentNullException(nameof(user));

        _logger.LogInformation("Processing user...");

        await DoWorkAsync(user.Id);
    }

    private Task DoWorkAsync(int id)
    {
        return Task.CompletedTask;
    }
}

The Result

• Token Reduction: ~45% reduction.
• Semantic Loss: 0%. The logic, structure, and dependency injection are identical.
• Readability: The output is cleaner and focuses entirely on what the code does.

---

CLI Reference

Option	Description
--all	Enables all optimizations below. Recommended for LLM context.
--aggressive	Enables attribute removal, property compression, and keyword cleanup.
--remove-csharp-namespaces	Flattens namespace structure and unindents code.
--remove-csharp-usings	Removes using statements.
--remove-csharp-comments	Removes all comments.
--remove-csharp-regions	Removes #region blocks.