Example of connecting to other dotnet processes

[ES0T]

I just saw this new feature : #477

This is extremely interesting. I don't totally follow how to use it though.
A small example would be very useful.

Thanks

[ES0T]

digging through the code a bit, I figured out how to connect. setting the ENVs, etc.

running a pretty standard ASPNET API with standard DI configured, I get DI provider captured: no — only statics and framework code are reachable.

So, I don't understand how to do anything once I am connected. I can't seem to find/use any of the static public properties inside my running dotnet app.

[waf]

Hi, thanks for the feedback. Yeah, I'm working on the usability of this a bit right now -- there are some sharp edges. I'm looking to get a release out in the next day or two to clean those up.

It's possible you chose the process id of the dotnet.exe host process, when it should be YourAppName.exe or similar. I have an unreleased feature, csharprepl connect list, that will narrow down the process list and make it easier to figure out which app to connect to.

It's totally possible (and interesting!) to connect to the dotnet.exe app, but you won't see your types in it, you'll instead see internal machinery like below, and there's no ServiceHost.

Example

Here is an example of connecting to some app called MyTargetApp. First, create a target application, and then run it with the env vars:

# make a new app
> dotnet new webapi -o MyTargetApp
The template "ASP.NET Core Web API" was created successfully.
Processing post-creation actions...
Restoring MyTargetApp.csproj:
Restore succeeded.

# get the env vars, and then set them (i.e. copy/paste these into the terminal to set them)
> csharprepl connect init --shell pwsh
$env:DOTNET_STARTUP_HOOKS = "C:\Path\To\CSharpRepl.InjectedHook.dll"
$env:ASPNETCORE_HOSTINGSTARTUPASSEMBLIES = "CSharpRepl.InjectedHook"

# run the app
> cd .\MyTargetApp\
> dotnet run

Then, from a different terminal / terminal tab, connect to it:

# find the process id of MyTargetApp.exe (a soon-to-be-released "csharprepl inspect list" command will help with this)
> (Get-Process -Name MyTargetApp).Id
39332

# inspect that process by ID
> csharprepl connect 39332
Connecting to the inspector in process 39332...
Connected to MyTargetApp (pid 39332)
  Runtime:   .NET 10.0.9
  Inspector: v1.0.0.0 (protocol v1)
  DI provider captured: yes — `services` and `Get<T>()` are available.

⚠ Development/diagnostics tool: code you evaluate runs inside the target process with its full privileges. Never inspect a production process.
Type C# to evaluate it in the target. Type exit (or press Ctrl+D) to detach; the target keeps running and you can reconnect later.

39332> using Microsoft.AspNetCore.Hosting;
39332> Get<IWebHostEnvironment>().ApplicationName
"MyTargetApp"

I have used this with a complex production-quality app, as well as smaller hello-world style apps. But I'm sure there are apps and setup patterns that csharprepl doesn't support yet. But pretty standard asp.net API apps should work fine.

[waf]

I've now shipped csharprepl inspect list csharprepl connect list

[ES0T]

thanks!! yeah... i was connecting to the dotnet process itself. that was the issue.

connecting to my specific app now works great, and I see the DI Get<T> and my namespaces.

I tested both my standard ASP NET app, as well as fairly complicated dotnet console app that does weird reflection and custom assembly loading stuff, and both worked great.

Off the top of my head, I don't have a lot of use cases for this yet, but I'm sure I'll come up with some. Very excited to play around with this.

Honestly, I would strongly recommend promoting this specific feature as well as this whole app on the C# and dotnet subreddits. I feel like this app is criminally unknown in the community. This is hands down one of my favorite dotnet specific tools.

[waf]

Thanks for the kind words! Now that I have the feature in a form I'm happy with, I'll be writing a blog post about how to use it.

By the way, I've renamed the subcommand from inspect to connect to avoid confusion with the existing dotnet-inspect command. So if you do upgrade, please watch out for that!