# 2dog

> 2dog runs Godot inside .NET: export your C# game to the browser, test it with xUnit, and embed the engine in any .NET application, with your scenes, scripts, and Godot workflow unchanged.

2dog is a free & open-source (MIT) toolkit that inverts Godot's ownership
model: instead of the Godot editor exporting your game, a plain .NET
application hosts the engine (libgodot) as a library. Your scenes, scripts,
and GodotSharp C# API stay exactly as they are - you gain `dotnet run`,
`dotnet publish` to desktop and browser (WebAssembly), real-engine xUnit and NUnit
tests, and embedding in any .NET app.
Current version: 4.7.2.134 (Godot 4.7.2).
NuGet packages: `2dog` (CLI tool) - https://www.nuget.org/packages/2dog/,
`2dog.templates` (dotnet new templates),
`2dog.engine` (the library), `2dog.xunit` (test collections),
`2dog.nunit` (NUnit fixtures).
Source: https://github.com/outfox/2dog

Every page below is also served as raw Markdown: replace `.html` with `.md`
(the URLs below already point at the Markdown versions). The entire site is
also available concatenated at https://2dog.dev/llms-full.txt.

## Start Here

- [Getting Started](https://2dog.dev/getting-started.md): Run Godot inside .NET applications with desktop, web, and test hosts.
- [Core Concepts](https://2dog.dev/concepts.md): How 2dog inverts Godot ownership: your .NET host owns the process and drives embedded libgodot, with GodotSharp API access, the main loop, resource paths, and the single-instance rule.
- [Project Layout](https://2dog.dev/project-layout.md): The recommended 2dog layout: the directory that contains project.godot is the .NET solution root, and small host projects for desktop, browser, and tests sit in folders that Godot ignores.

## Hosts

- [What's a Host?](https://2dog.dev/hosts/index.md): Choose a .NET application that starts Godot for your game or tests.

## Console Hosts

- [2dog (generic .NET)](https://2dog.dev/hosts/generic.md): Run and publish your Godot game as a .NET console application.
- [C# REPL](https://2dog.dev/hosts/repl.md): Explore and change a running Godot game with C# and shell-like commands.

## Desktop Hosts

- [Avalonia](https://2dog.dev/hosts/avalonia.md): Embed Godot in a cross-platform Avalonia window with controls over the game.
- [Qt Quick](https://2dog.dev/hosts/qt.md): Embed Godot in a Qt Quick (QML) app built with Qt Bridge for C#, with QML items over the game.
- [WinForms](https://2dog.dev/hosts/winforms.md): Embed Godot in a Windows Forms window.
- [WinUI 3](https://2dog.dev/hosts/winui.md): Embed Godot in a Windows App SDK window.

## Web Hosts

- [Blazor](https://2dog.dev/hosts/blazor.md): Embed Godot in a Blazor WebAssembly page with GodotView.
- [Web](https://2dog.dev/hosts/web.md): Publish your Godot C# game as a static browser site with the browser-wasm host.
- [WebXR](https://2dog.dev/hosts/webxr.md): Run Godot VR and AR in the browser with WebXR and the WebXR Layers polyfill.

## Mobile Hosts

- [Android](https://2dog.dev/hosts/android.md): Package your Godot C# game as an Android APK with the experimental Android host.
- [iOS](https://2dog.dev/hosts/ios.md): Run your Godot C# game as an iOS app with the experimental iOS host, built on a Mac with Xcode.
- [MAUI](https://2dog.dev/hosts/maui.md): Embed Godot in a .NET MAUI page on Windows, Android and, experimentally, iOS.

## Testing Hosts

- [GdUnit](https://2dog.dev/hosts/gdunit.md): Run GDScript GdUnit suites through a .NET test host with embedded Godot.
- [NUnit](https://2dog.dev/hosts/nunit.md): Add an NUnit test project alongside your Godot game.
- [xUnit](https://2dog.dev/hosts/xunit.md): Add an xUnit test project alongside your Godot game.

## API Reference

- [API Reference](https://2dog.dev/api-reference.md): Overview of the deliberately small 2dog API: twodog.Engine, Godot.GodotInstance, the twodog.Testing fixtures, xUnit collections, and object lifetimes at a glance.
- [twodog.Engine](https://2dog.dev/api/engine.md): API reference for twodog.Engine, which configures, starts, and owns one embedded Godot instance: constructor, properties, Start, Run, Dispose, and common Godot arguments.
- [Godot.GodotInstance](https://2dog.dev/api/godot-instance.md): API reference for Godot.GodotInstance, the borrowed compatibility handle returned by Engine.Start().
- [GodotSharp](https://2dog.dev/api/godotsharp.md): API stub for GodotSharp, which 2dog exposes.
- [Fixtures](https://2dog.dev/api/fixture-base.md): API reference for 2dog's test fixtures and xUnit collections: FixtureBase, HeadlessFixture, Fixture, HeadlessCollection and RenderingCollection.
- [twodog.fixture.AssemblyPreloader](https://2dog.dev/api/assembly-preloader.md): API reference for AssemblyPreloader, which preloads game assemblies into the default AssemblyLoadContext before Godot starts.

## Develop and Configure

- [dnx 2dog](https://2dog.dev/dnx-2dog.md): Reference for the 2dog command-line tool: installation, commands, host flags, global and output options, exit codes, version pinning.
- [2dog add](https://2dog.dev/cli/add.md): Reference for 2dog add: add .NET hosts to an existing Godot project in place - arguments, host flags, options, examples.
- [2dog new](https://2dog.dev/cli/new.md): Reference for 2dog new: create a Godot project with 2dog hosts - arguments, host flags, options, examples.
- [2dog doctor](https://2dog.dev/cli/doctor.md): Reference for 2dog doctor: check a 2dog project and the machine, apply fixes, explain build failures - options, exit codes, every check id.
- [2dog update](https://2dog.dev/cli/update.md): Reference for 2dog update: bring a project's 2dog packages to the running tool's versions - arguments, options, examples.
- [2dog pack](https://2dog.dev/cli/pack.md): Reference for 2dog pack list: list an exported .pck's contents by size, without an engine or project.
- [2dog repl](https://2dog.dev/cli/repl.md): Attach to a running REPL host or execute C# and node commands from scripts and agents.
- [2dog skill](https://2dog.dev/cli/skill.md): Reference for 2dog skill: write the REPL working guide where Claude Code, Codex and other coding agents read project instructions.
- [Pinning](https://2dog.dev/cli/pinning.md): Choose which version of the 2dog tool to run and keep your project's package versions fixed.
- [2dog version](https://2dog.dev/cli/version.md): Reference for 2dog version: print the tool version and every package a setup references, checked against nuget.org.
- [2dog help](https://2dog.dev/cli/help.md): Reference for 2dog help: show the tool's usage, or the help for one verb.
- [Resource Import](https://2dog.dev/import-tool.md): How 2dog imports Godot resources and exports game packs during MSBuild: incremental imports driven by GodotProjectDir, the twodog.import helper, pack contents, and troubleshooting.
- [Build Variants](https://2dog.dev/build-configurations.md): Choosing debug, release and editor variants with single or double precision.
- [Environment Variables](https://2dog.dev/configuration/environment-variables.md): Environment variables for 2dog debugging, diagnostics, CLI output, assembly loading, and Android builds.

## Testing

- [Testing](https://2dog.dev/testing/index.md): Test your Godot game with GdUnit, xUnit or NUnit, from a first test to signals and simulated input.
- [Testing GDScript with GdUnit](https://2dog.dev/testing/gdunit.md): Understand how the 2dog host changes GdUnit execution, resource isolation and test reporting.
- [Testing with NUnit](https://2dog.dev/testing/nunit.md): Write Godot tests with NUnit's headless or rendering fixture.
- [Testing with xUnit](https://2dog.dev/testing/xunit.md): Write your first Godot test with xUnit and choose a shared engine fixture.
- [Writing Engine Tests](https://2dog.dev/testing/writing-tests.md): Wait for Godot frames, assert signals, and clean up test state in xUnit and NUnit.
- [Simulating Input](https://2dog.dev/testing/input.md): Click Godot controls and send keyboard events in xUnit and NUnit tests.

## MSBuild Configuration

- [MSBuild Configuration](https://2dog.dev/configuration.md): Shared 2dog settings, package versions, and configuration references for each host.

## Console Configuration

- [Generic .NET Configuration](https://2dog.dev/configuration/generic.md): MSBuild settings for the generic .NET host: console behavior, desktop pack export, and Native AOT.
- [REPL Configuration](https://2dog.dev/configuration/repl.md): Configure REPL native variants, headless runs, local connections and publishing.

## Desktop Configuration

- [Avalonia Configuration](https://2dog.dev/configuration/avalonia.md): MSBuild settings for Avalonia hosts: shared engine settings, desktop pack export, and Native AOT.
- [Qt Quick Configuration](https://2dog.dev/configuration/qt.md): MSBuild and session settings for Qt Quick hosts: Qt location, the TwoDog QML module, and presentation.
- [WinForms Configuration](https://2dog.dev/configuration/winforms.md): MSBuild settings for WinForms hosts: Windows targeting, pack export, runtime bundling, and trimming limitations.
- [WinUI 3 Configuration](https://2dog.dev/configuration/winui.md): MSBuild settings for WinUI 3 hosts: desktop packs, self-contained Windows App SDK deployment, and Native AOT.

## Web Configuration

- [Blazor Configuration](https://2dog.dev/configuration/blazor.md): MSBuild configuration for the Blazor WebAssembly client: game packs, native symbols, memory, and SDK-managed compression.
- [Web Configuration](https://2dog.dev/configuration/web.md): MSBuild properties for browser-wasm hosts: native variants, game packs, symbols, compression, and Mono AOT.
- [WebXR Configuration](https://2dog.dev/configuration/webxr.md): MSBuild configuration for WebXR hosts, using the Web host's browser engine, pack, compression, and AOT settings.

## Mobile Configuration

- [Android Configuration](https://2dog.dev/configuration/android.md): MSBuild configuration for experimental Android hosts: native variants, game packs, signing, trimming, and Native AOT.
- [iOS Configuration](https://2dog.dev/configuration/ios.md): MSBuild configuration for experimental iOS hosts: native variants, game packs, signing, trimming, and the interpreter.
- [MAUI Configuration](https://2dog.dev/configuration/maui.md): Configure MAUI targets, GodotView rendering and publishing.

## Testing Configuration

- [GdUnit Configuration](https://2dog.dev/configuration/gdunit.md): Configure GdUnit host packages, private resource roots, execution limits and artifacts.
- [NUnit Configuration](https://2dog.dev/configuration/nunit.md): Configure NUnit hosts, engine variants, Editor bindings and headless fixtures.
- [xUnit Configuration](https://2dog.dev/configuration/xunit.md): MSBuild configuration for xUnit hosts: engine variants, resource import, and Editor API references.

## Known Issues

- [Known Issues](https://2dog.dev/known-issues/index.md): Current 2dog limitations and their workarounds: one Godot instance per load context, xUnit discovery crashes with Godot types, GD.Print visibility in tests, and spaced project names breaking publish.
- [Single Godot Instance](https://2dog.dev/known-issues/single-instance.md): Only one Godot instance may run per assembly load context in 2dog; sequential restart is supported and isolated concurrent hosting is experimental.
- [xUnit Test Discovery Crash](https://2dog.dev/known-issues/xunit-discovery.md): Godot values in xUnit MemberData can crash the test host during discovery - the affected Godot types and the workarounds.
- [GD.Print in Tests](https://2dog.dev/known-issues/gd-print-output.md): Why GD.Print output is hidden during dotnet test, how to make it visible, and why ITestOutputHelper is the recommended pattern.
- [Spaced Project Names](https://2dog.dev/known-issues/spaced-project-names.md): Whitespace in the game project's .NET name makes dotnet publish silently drop its NuGet dependencies from 2dog hosts - an upstream .NET SDK bug 2dog guards against.

## Optional

- [FAQ](https://2dog.dev/faq.md): Frequently asked questions about 2dog: how it differs from godot-dotnet, GodotSharp compatibility, separate tool and engine packages, and frame rate caps in the browser.
- [Troubleshooting](https://2dog.dev/troubleshooting.md): Learn what 2dog's exit codes and errors mean, how the tool behaves in CI and pipes, and how to fix restore, build and runtime problems.