Add Unity package wrapper and netstandard SDK target

[Copilot]

Enable a Unity-friendly wrapper around Nodetool.SDK while keeping the core SDK Unity-free, and ensure the SDK can be consumed by Unity via a netstandard2.1 build with minimal API compatibility fixes.

• Unity package (Runtime/Editor/Samples)
  • Added a UPM package with bridge, settings, dispatcher, Unity asset conversion helpers, logging adapter, and a BasicWorkflow sample scene/script.
• SDK compatibility for Unity
  • Multi-targeted Nodetool.SDK/Nodetool.Types for netstandard2.1, added init-only shim, netstandard-safe I/O/HTTP overloads, and patched System.Text.Json versions.
• Packaging docs/meta
  • Included package README, plugin DLL placement guide, and Unity .meta assets.

Example (Unity workflow execution):

var result = await NodetoolBridge.Instance.RunWorkflowAsync(
    "text_to_image",
    new Dictionary<string, object> { ["prompt"] = "A scenic landscape at sunset" }
);

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• packages.stride3d.net
  • Triggering command: /usr/bin/dotnet dotnet build /home/REDACTED/work/nodetool-sdk/nodetool-sdk/csharp/Nodetool.SDK/Nodetool.SDK.csproj -c Release d -n 10 (dns block)
  • Triggering command: /opt/hostedtoolcache/CodeQL/2.23.9/x64/codeql/csharp/tools/linux64/Semmle.Autobuild.CSharp /opt/hostedtoolcache/CodeQL/2.23.9/x64/codeql/csharp/tools/linux64/Semmle.Autobuild.CSharp (dns block)
• teamcity.vvvv.org
  • Triggering command: /usr/bin/dotnet dotnet build /home/REDACTED/work/nodetool-sdk/nodetool-sdk/csharp/Nodetool.SDK/Nodetool.SDK.csproj -c Release d -n 10 (dns block)
  • Triggering command: /opt/hostedtoolcache/CodeQL/2.23.9/x64/codeql/csharp/tools/linux64/Semmle.Autobuild.CSharp /opt/hostedtoolcache/CodeQL/2.23.9/x64/codeql/csharp/tools/linux64/Semmle.Autobuild.CSharp (dns block)
  • Triggering command: /usr/bin/dotnet dotnet restore --no-dependencies /home/REDACTED/work/nodetool-sdk/nodetool-sdk/csharp/Nodetool.SDK.VL/Nodetool.SDK.VL.csproj --packages /home/REDACTED/work/nodetool-sdk/.codeql-scratch/dbs/csharp/working/packages /p:DisableImplicitNuGetFallbackFolder=true --verbosity normal /p:TargetFrameworkRootPath=/home/REDACTED/work/nodetool-sdk/.codeql-scratch/dbs/csharp/working/emptyFakeDotnetRoot /p:NetCoreTargetingPackRoot=/home/REDACTED/work/nodetool-sdk/.codeql-scratch/dbs/csharp/working/emptyFakeDotnetRoot lesspipe (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

Nodetool.SDK.Unity Integration Guide

Overview

This document outlines the approach for integrating Nodetool workflows into Unity projects. The goal is to create a Unity-friendly wrapper around the existing Nodetool.SDK that works in both Editor and Runtime.

Integration Policy (Core SDK vs Unity Layer)

• Default: Treat Nodetool.SDK as the core library. Unity integration should live in a separate Unity-facing layer/package that wraps and uses the SDK.
• Allowed core changes: Changes to Nodetool.SDK are allowed only when required for Unity compatibility or to fix correctness issues exposed by Unity usage.
• Non-breaking requirement: Any change to Nodetool.SDK must not break existing functionality. Validate by running the existing .NET smoke path (at minimum csharp/Nodetool.SDK/TestConsole) and keeping public APIs stable.
• No Unity dependencies in core: Keep UnityEngine (and any Unity-only APIs) out of Nodetool.SDK. Unity-specific code belongs in the Unity layer.

Success Criteria

• MVP: A small Unity sample (scene + scripts) that can run a Nodetool workflow end-to-end.
• Editor + runtime: Works in Unity Editor (play mode) and a standalone build (runtime).
• Unity assets: Demonstrate at least one asset integration path (e.g. Texture2D → workflow input and an image-like output → Texture2D).
• Reuse the SDK: Use existing Nodetool.SDK components for worker execution (WebSocket, execution session, asset handling) where possible.

---

Architecture

┌─────────────────────────────────────────────────────────────┐
│                     Unity Application                        │
├─────────────────────────────────────────────────────────────┤
│  Nodetool.SDK.Unity                                          │
│  ├── NodetoolBridge.cs         (MonoBehaviour singleton)     │
│  ├── UnityAssetManager.cs      (Unity asset conversion)      │
│  ├── NodetoolWorkflowRunner.cs (Coroutine-friendly API)      │
│  └── UnityLogging.cs           (Debug.Log integration)       │
├─────────────────────────────────────────────────────────────┤
│  Nodetool.SDK (existing)                                     │
│  ├── NodeToolExecutionClient                                 │
│  ├── MessagePackWebSocketClient                              │
│  ├── AssetManager                                            │
│  └── Types & Models                                          │
└─────────────────────────────────────────────────────────────┘

---

Phase 0: Make Nodetool.SDK Unity-Consumable (Only If Needed)

Unity typically consumes prebuilt assemblies targeting a Unity-compatible framework (commonly .NET Standard 2.1) and runs under Editor/Mono or Player/IL2CPP. Nodetool.SDK currently targets net8.0, so we should plan for a Unity-loadable build.
If the current SDK already works as-is in the target Unity version/platform, keep it unchanged.

• Prefer prebuilt DLLs in Unity: Avoid compiling Nodetool.SDK source inside Unity. Unity’s C# compiler/version can lag behind and may not accept modern SDK source constructs (e.g. required), while Unity can still load a compatible prebuilt DLL.
• Multi-target the SDK: Add a Unity-compatible target to Nodetool.SDK (recommended: netstandard2.1) while keeping net8.0 for normal .NET usage.
• Remove/replace net8-only APIs (examples found in current code):
  • Convert.ToHexString(...) (replace with a netstandard-friendly hex encoder)
  • File.WriteAllBytesAsync(..., CancellationToken) (use compatible overload / manual stream write)
  • HttpContent.CopyToAsync(..., CancellationToken) (use compatible overloads)
• Decide JSON strategy: Nodetool.SDK currently uses System.Text.Json in multiple places. For Unity:
  • Either ship the dependency with the Unity package (and verify IL2CPP compatibility), or
  • Refactor JSON usage to be optional / limited to debug helpers (preferred for portability).
• Prove non-breaking: After any core SDK changes, run csharp/Nodetool.SDK/TestConsole (and existing tests if present) to confirm behavior is unchanged for normal .NET consumers.

Phase 1: Project Setup

1.1 Create Unity Package Structure

Packages/
└── com.nodetool.sdk/
    ├── package.json
    ├── Runtime/
    │   ├── Plugins/
    │   │   ├── Nodetool.SDK.dll
    │   │   ├── Nodetool.Types.dll
    │   │   ├── MessagePack.dll
    │   │   ├── Microsoft.Extensions.Logging.Abstractions.dll
    │   │   └── (other dependency DLLs as needed)
    │   ├── Nodetool.SDK.Unity.asmdef
    │   ├── Core/
    │   │   ├── NodetoolBridge.cs
    │   │   ├── NodetoolConnection.cs
    │   │   └── NodetoolSettings.cs
    │   ├── Assets/
    │   │   ├── UnityAssetManager.cs
    │   │   └── AssetConverters.cs
    │   └── Utilities/
    │       ├── MainThreadDispatcher.cs
    │       └── UnityLogger.cs
    ├── Editor/
    │   ├── Nodetool.SDK.Unity.Editor.asmdef
    │   ├── NodetoolSettings...

</details>



<!-- START COPILOT CODING AGENT TIPS -->
---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more [Copilot coding agent tips](https://gh.io/copilot-coding-agent-tips) in the docs.