Introduction

Yes, the C# Interactive window can work with your code, but not in a magical "reach into any running process" sense. It is a REPL that can evaluate snippets, load source files, and reference compiled assemblies from your solution. That makes it useful for experimenting with your code, but it is not a replacement for a debugger attached to live application state.

Use It with Referenced Assemblies

One of the simplest ways to interact with your own code is to reference the compiled output of a project. Once the assembly is loaded, you can instantiate types and call methods directly.

Suppose your project contains this class:

1namespace DemoApp;
2
3public class PriceCalculator
4{
5    public decimal AddTax(decimal amount) => amount * 1.13m;
6}

In C# Interactive, you can load the built assembly with #r:

1#r "C:\\Projects\\DemoApp\\bin\\Debug\\net8.0\\DemoApp.dll"
2
3using DemoApp;
4
5var calc = new PriceCalculator();
6calc.AddTax(100m)

That lets you try real code from the project without editing the application entry point or creating a throwaway console app.

Load Scripts or Source for Quick Experiments

If you are working with small helper scripts, #load can be useful:

#load "helpers.csx"

GetGreeting("Mark")

This is especially convenient for prototype code, one-off utilities, or small bits of reusable logic that fit naturally into script files.

Inside Visual Studio, you can also send selected code to the Interactive window. That is a good way to test a method body or expression in isolation without switching to a full run-debug cycle.

What It Can and Cannot See

The key limitation is context. C# Interactive can execute code against referenced assemblies, but it does not automatically inherit the state of a running web request, desktop UI session, or background service process.

For example, if your application builds objects through dependency injection, the REPL does not automatically know about that container unless you recreate or reference it deliberately.

A simple manual setup might look like this:

1#r "C:\\Projects\\DemoApp\\bin\\Debug\\net8.0\\DemoApp.dll"
2
3using DemoApp;
4
5var service = new PriceCalculator();
6service.AddTax(25m)

That is interaction with your code, but not with the current in-memory state of a running application instance.

Good Uses for C# Interactive

The tool is strongest when you want to:

• test a method quickly
• inspect how an API behaves
• prototype LINQ queries
• verify serialization logic
• experiment with referenced libraries

For example, trying a quick LINQ expression:

var numbers = new[] { 1, 2, 3, 4, 5 };
numbers.Where(n => n % 2 == 0).ToArray()

This kind of feedback loop is much faster than creating a full program every time.

When the Debugger Is the Better Tool

If you need access to the actual runtime state of a live application, breakpoints, watch windows, immediate windows, and debugger visualizers are the better fit. The Interactive window is not designed to inspect an arbitrary object graph from another process just because that process happens to be your code.

Think of it as an execution sandbox for your code, not as a universal runtime console attached to everything your program is currently doing.

Common Pitfalls

One common mistake is expecting the REPL to know about unbuilt project changes. If the assembly on disk is stale, Interactive will reflect the old code until you rebuild.

Another mistake is assuming it can automatically interact with live ASP.NET request state, WinForms control trees, or other process-local runtime objects. It cannot unless you deliberately expose and recreate the necessary context.

Developers also sometimes forget to reference the right output assembly or the right target framework directory. If #r points to the wrong build output, types may fail to load.

Finally, the Interactive window is best for small experiments. Once the setup becomes elaborate, a unit test or dedicated console harness is usually clearer and more repeatable.

Summary

• The C# Interactive window can execute against your code by loading scripts or compiled assemblies.
• It is useful for experiments, API checks, and small prototype runs.
• It does not automatically attach to or inspect arbitrary live runtime state from your application.
• Use #r for assemblies and #load for script files.
• For real runtime inspection, the debugger is still the better tool.