Lockjaw

The Lockjaw Visual Studio extension: a docked tool window that switches your applications' settings between environments while you debug, one instance per Startup Project. It brings the desktop Lockjaw experience inside the IDE — the same environment switcher, hosted in-proc — and works with Visual Studio's multiple-startup-project debugging.

net472 (devenv.exe is a .NET Framework host), an in-proc VSSDK AsyncPackage. It reuses Lockjaw's real WPF UI (Lockjaw.Ui) and engine (Lockjaw.Core) — no second implementation.

What it does

When you open a solution, Lockjaw:

1. Loads automatically (it auto-loads on solution open, before you hit F5).
2. Reads that solution's Startup Projects and maps each to a Lockjaw instance — keyed by the project's assembly name, pointed at that project's App.config or appsettings.json.
3. Publishes each instance's resolved values, exactly as the desktop app does, to %LOCALAPPDATA%\Lockjaw\shared\<instance>\resolved.json.
4. Shows them all in the Lockjaw tool window (docked right, in the document well). Switch any application's environment there and the debugged process reads the new values live.

So while several projects debug together, each one's settings can point at a different environment, and you can repoint any of them mid-session without stopping.

The debugged-app contract

The application being debugged references Lockjaw.Client and opts into discovery — it finds its own instance by assembly name, with no instance name to configure:

using var client = new LockjawClient(new LockjawClientOptions
{
    AutoDiscoverInstance = true
});

var apiUrl = client.Get("ApiUrl");
var main   = client.GetConnectionString("Main");

client.SettingChanged += (s, e) =>
{
    // Fires when you switch this app's environment in the Lockjaw tool window.
};

AutoDiscoverInstance looks through every instance published on the machine for one whose applications include this app's name (the entry assembly's name by default; override with ApplicationName). That is exactly what the extension records for each Startup Project, so the two find each other with no wiring. When nothing matches — the extension isn't running, or this isn't a mapped project — the client falls back to the default instance and then to the app's own config, so the same code runs unchanged outside Visual Studio. See samples/Lockjaw.Sample.Client for a working example.

Instances persist across rebuilds and sessions

The per-solution instance list lives outside the build output, at:

%LOCALAPPDATA%\Lockjaw\solutions\<solution-name>-<hash>\instances.json

• It is keyed by the solution, so two solutions never mix.
• A rebuild never touches it — it is not in bin/obj.
• On solution open the extension merges: it keeps every existing definition and your edits, and only adds Startup Projects it hasn't seen. A project you removed from the solution is not auto-deleted; remove it yourself with Manage applications….

Your per-application environment choices and edits persist too, in the same %LOCALAPPDATA%\Lockjaw\<instance>\ files the desktop app uses — so the environment you selected for an app last session is still selected the next time you debug it.

Lockjaw is a development aid. Keep production credentials out of configuration that reaches end users; the window will display any value it is given.