DEV Community: Dutchskull

Run Unity3D as a First‑Class Service with .NET Aspire (Aspire.Unity experimental)

Dutchskull — Wed, 24 Sep 2025 15:30:47 +0000

.NET Aspire is a cloud‑native application model for composing APIs, databases, and background workers into a single distributed AppHost. Aspire.Unity (experimental) integrates Unity3D into that model so your Unity project starts, stops, and receives Aspire configuration as part of the same AppHost lifecycle — treating Unity like any other service in your topology.

Repo: https://github.com/Dutchskull/Aspire.Unity3D

Why bring Unity into Aspire?

Run Unity as a service alongside APIs, workers, and databases.
Start and stop Unity automatically with your AppHost.
Pass Aspire configuration and environment variables into the Unity runtime at startup.
Use Unity for live data visualization, server-driven simulation, automated play‑mode tests, or developer tooling integrated into your distributed app.

Quick install

Add the NuGet package to your AppHost project:

dotnet add package Dutchskull.Aspire.Unity

In Unity Package Manager add the Git packages:
https://github.com/Dutchskull/Unity.Configuration.git?path=/Unity.Configuration/Packages/Unity.Configuration
https://github.com/Dutchskull/Aspire.Unity3D.git?path=/AspireIntegration/Packages/AspireIntegration

Minimal example

Add one line to your AppHost to register a Unity project:

var unity = builder.AddUnityProject("game", "..\\..\\AspireIntegration", 1);

This:

Registers a Unity project named "game".
Uses the relative path "..\..\AspireIntegration".
Starts Unity at the default URL http://127.0.0.1:54021.
Opens the scene at index 1 and starts Play mode.

Advanced usage

Two overloads let you choose scene by index or name and customize URL, port, and Unity install root:

public static IResourceBuilder<UnityProjectResource> AddUnityProject(
    this IDistributedApplicationBuilder builder,
    string name,
    string projectPath,
    int? sceneIndex = null,
    string url = "http://127.0.0.1",
    int port = 54021,
    string? customUnityInstallRoot = null) {...}

public static IResourceBuilder<UnityProjectResource> AddUnityProject(
    this IDistributedApplicationBuilder builder,
    string name,
    string projectPath,
    string? sceneName = null,
    string url = "http://127.0.0.1",
    int port = 54021,
    string? customUnityInstallRoot = null) {...}

Example with all arguments:

var unity = builder.AddUnityProject(
    name: "game",
    projectPath: "..\\..\\AspireIntegration",
    url: "http://localhost",
    port: 55000,
    customUnityInstallRoot: "E:\\Unity"
);

Configuration: Aspire config inside Unity

Aspire.Unity exposes Aspire configuration directly to the Unity runtime via the Unity-side ConfigProvider static object:

ConfigProvider.Configuration

What this enables:

Environment variables, appsettings, secrets and other Aspire configuration sources are available inside Unity at startup.
Inject API base URLs, feature flags, or credentials into Unity without hardcoding.
Drive scene logic, simulation parameters, and runtime behavior from Aspire configuration.
Support multiple environments (development, staging, production) transparently for Unity.

Tip: Use ConfigProvider.Configuration to read typed settings or feature flags in Awake/Start so your scene boots with the correct runtime values.

Example scenarios

Real‑time dashboards: Visualize telemetry from Aspire APIs inside Unity scenes.
Server‑driven simulation: Aspire coordinates runs; Unity executes simulations and reports results back.
CI play‑mode tests: Launch Unity in AppHost to run automated tests as part of your pipeline.
Developer tooling: Expose an interactive scene preview or visualization service for local development.

Roadmap

Planned improvements include:

Integrating with Open-telemetry

Try it

Main repo: https://github.com/Dutchskull/Aspire.Unity3D
Unity config package: https://github.com/Dutchskull/Unity.Configuration

This project is experimental but already useful for prototyping Aspire + Unity workflows. I’d love to hear how you’d combine Aspire and Unity — visualization, simulations, CI testing, or developer tooling?

Adjusting Scroll Speed on Linux: A Quick Guide

Dutchskull — Sat, 12 Jul 2025 10:22:30 +0000

I had been looking for how to configure this for a while, and then came by this original post. Down here there is a very concise version of the same thing.

If you find your scroll speed too fast or too slow on Ubuntu 22.04, you can easily adjust it using the command line. Here’s a step-by-step guide to help you customize your touchpad scroll speed system-wide.

Step 1: Install Required Tools

Open your terminal (Ctrl + Alt + T) and install the libinput-tools package:

sudo apt install libinput-tools

Step 2: Measure Touchpad Size

Run the following command to get your touchpad dimensions:

sudo libinput measure touchpad-size 100x100

Note the dimensions (e.g., 93.9x66.6mm) and round them to whole numbers.

Step 3: Calculate Desired Scroll Speed

Decide your desired scroll speed (e.g., 0.5 for half speed). Multiply your dimensions by this factor:

For example, 94 x 0.5 = 47 and 66 x 0.5 = 33. Run the command again with your new dimensions:

sudo libinput measure touchpad-size 47x33

Follow the terminal instructions to complete the measurement.

Step 4: Copy Output

After finishing the measurement, copy the output between the lines marked with -<8----------------.

Example

-8<--------------------------
# Laptop model description (e.g. Lenovo X1 Carbon 5th)
evdev:name:DLL07BE:01 06CB:7A13 Touchpad:dmi:*svnDellInc.:*pnXPS159560**
 EVDEV_ABS_00=::16
 EVDEV_ABS_01=::21
 EVDEV_ABS_35=::16
 EVDEV_ABS_36=::21
-8<--------------------------

Step 5: Edit Configuration File

Open the configuration file:

sudo nano /etc/udev/hwdb.d/61-evdev-local.hwdb

Paste the copied lines, then save and exit (Ctrl + X).

Step 6: Update and Reload

Update the hardware database and reload udev rules:

sudo systemd-hwdb update
sudo udevadm trigger /dev/input/event*

Final Step: Reboot

Restart your computer for the changes to take effect. Adjust the touchpad speed in “Settings -> Mouse & Touchpad” if needed.

Resetting to Default

To revert to default settings, delete the config file:

sudo rm /etc/udev/hwdb.d/61-evdev-local.hwdb

Then update and reload as before, followed by a restart.

This process may seem lengthy, but it’s straightforward and allows you to tailor your Linux experience to your preferences. Happy scrolling!

Enabling Mixed Content in Blazor Apps on Android: A Step-by-Step Guide

Dutchskull — Thu, 21 Nov 2024 09:44:01 +0000

In modern web development, serving content over HTTPS is a best practice to ensure security and privacy. However, there are scenarios where you might need to load resources over HTTP, especially when dealing with legacy systems or third-party content. In this blog post, we will explore how to enable mixed content in a Blazor app running on an Android emulator, allowing you to display both HTTP and HTTPS images.

Problem Statement

When you attempt to load an HTTP image in a Blazor app on Android, you may encounter a "failed image load" error due to the default security settings that block mixed content. This is a common issue when trying to integrate resources from both HTTP and HTTPS sources.

Solution Overview

To resolve this issue, we need to make two key changes:

Configure the WebView to allow mixed content.
Update the Android manifest to permit cleartext (non-HTTPS) traffic.

Step 1: Modify the BlazorWebView Configuration

First, we need to register an event handler for the BlazorWebViewInitialized event in the MainPage.xaml file. This will allow us to configure the WebView settings when it is initialized.

Update `MainPage.xaml`

Add the BlazorWebViewInitialized attribute to the <BlazorWebView> tag:

<BlazorWebView HostPage="wwwroot/index.html" BlazorWebViewInitialized="Bwv_BlazorWebViewInitialized">
</BlazorWebView>

Implement the Event Handler in `MainPage.xaml.cs`

Next, we will implement the Bwv_BlazorWebViewInitialized method in the code-behind file to set the mixed content mode:

private void Bwv_BlazorWebViewInitialized(object sender, Microsoft.AspNetCore.Components.WebView.BlazorWebViewInitializedEventArgs e)
{
#if ANDROID
    e.WebView.Settings.MixedContentMode = Android.Webkit.MixedContentHandling.AlwaysAllow;
#endif
}

This code snippet ensures that the WebView allows mixed content, which is essential for loading HTTP resources alongside HTTPS ones.

Step 2: Update the Android Manifest

The next step is to modify the Android manifest file to allow cleartext traffic. This is done by setting the android:usesCleartextTraffic attribute to true.

Update `AndroidManifest.xml`

Locate the <application> tag in Platforms\Android\AndroidManifest.xml and add the android:usesCleartextTraffic attribute:

<application android:allowBackup="true" 
             android:icon="@mipmap/appicon" 
             android:roundIcon="@mipmap/appicon_round" 
             android:supportsRtl="true" 
             android:usesCleartextTraffic="true">
</application>

This change permits the app to load HTTP resources, addressing the mixed content issue.

Step 3: Test the Implementation

Now that we have made the necessary changes, it’s time to test the implementation. In one of your .razor files (e.g., Counter.razor), add the following <img> tags:

<img width="100" height="100" src="http://some-url.com/image" />
<img width="100" height="100" src="https://some-url.com/image" />

When you run the app in the Android emulator, both images should load successfully, demonstrating that the mixed content configuration is working as intended.

Conclusion

By following the steps outlined in this blog post, you can enable mixed content in your Blazor app running on Android. This allows you to load resources from both HTTP and HTTPS sources, which can be particularly useful in scenarios where you need to integrate legacy content. Always remember to consider the security implications of allowing mixed content and use it judiciously.

Feel free to reach out if you have any questions or if you encounter any issues while implementing this solution!

Building a Complex Form with React Hook Form and Yup

Dutchskull — Wed, 25 Sep 2024 09:09:40 +0000

Creating forms in web applications can often be a daunting task, especially when it comes to managing state and validation. In this blog post, we will explore how to build a complex form using React Hook Form and Yup for validation, while keeping our code clean and maintainable. For a complete implementation, you can check out the GitHub repository.

Overview of the Form

The form we are building allows users to create a book store by entering the store's name and adding multiple books. Each book entry includes a title, amount, and binding type. This form leverages the power of React Hook Form for state management and Yup for validation, ensuring a smooth user experience.

Key Components

1. Form Component

The main component of our form is responsible for rendering the overall structure and handling form submission. It utilizes useForm from React Hook Form to manage the form state and useFieldArray to handle dynamic book entries.

Key Features:

Dynamic Fields: Users can add or remove book entries dynamically.
Validation: The form validates user input using Yup, ensuring that all required fields are filled out correctly.

Code Snippet:

const { control, register, handleSubmit, formState: { errors } } = useForm<BookStore>({
  resolver: yupResolver(bookStoreValidationScheme),
  defaultValues: {
    name: "",
    books: [],
  },
});

Why Use This?

Using useForm with a resolver allows us to easily integrate Yup validation into our form. This setup simplifies form state management and ensures that validation rules are applied consistently.

2. BookInputRow Component

This component represents a single row for book input. It allows users to enter details for each book, including the title, amount, and binding type.

Key Features:

Autocomplete for Binding Type: Users can select the binding type from a predefined list, enhancing usability.
Error Handling: Each input field displays validation messages when the user input is invalid.

Code Snippet:

<Controller
  control={props.control}
  name={`books.${props.index}.binding`}
  render={({ field }) => (
    <Autocomplete
      {...field}
      options={bookTypes}
      onChange={(_, value) => field.onChange(value)}
      renderInput={(params) => (
        <TextField
          {...params}
          label="Book Type"
          error={!!props.errors.books?.[props.index]?.binding}
          helperText={props.errors.books?.[props.index]?.binding?.message}
          fullWidth
        />
      )}
    />
  )}
/>

Why Use This?

The Controller component allows us to integrate third-party components like Autocomplete with React Hook Form. This approach provides a seamless way to manage form state while leveraging the rich features of MUI components.

3. Validation Schema

We define a validation schema using Yup to enforce rules on the form fields. This schema ensures that:

The book store name is required.
Each book entry must have a title, amount, and binding type.
At least one book must be added to the form.

Code Snippet:

export const bookStoreValidationScheme = yup.object().shape({
  name: yup.string().required("Name is required"),
  books: yup.array().of(
    yup.object().shape({
      title: yup.string().required("Book title is required"),
      amount: yup.number().required("Amount is required").positive("Amount must be more than 1").integer("Amount must be an integer"),
      binding: yup.string().required("Book type is required"),
    })
  ).min(1, "You need to add at least one book").required("You need to add at least one book"),
});

Why Use This?

Using Yup for validation allows us to define clear and concise rules for our form fields. This not only improves the user experience by providing immediate feedback but also ensures that the data submitted is valid and meets our requirements.

How to Set Up the Project

To get started with your own implementation, you can clone the repository:

git clone https://github.com/WhiteOlivierus/ReactMuiFormYup.git
cd ReactMuiFormYup
npm install
npm run dev

This will set up the project with all necessary dependencies, and you can start exploring the code.

Conclusion

In this post, we have discussed the key components of a complex form built with React Hook Form and Yup. By leveraging these libraries, we can create forms that are not only functional but also user-friendly and maintainable. For the complete code and further details, be sure to check out the GitHub repository. Happy coding!

Monitoring GameObject Changes in the Unity editor hierarchy

Dutchskull — Wed, 10 Jul 2024 08:29:24 +0000

Introduction

Managing GameObjects in Unity can be a complex task, especially when dealing with dynamic and interactive scenes. Detecting changes such as additions, deletions, renaming, and parent changes in the hierarchy is crucial for many applications. In this post, we will walk through a powerful script, HierarchyMonitor, which helps in tracking these changes in real-time within the Unity Editor.

Overview of `HierarchyMonitor`

The HierarchyMonitor script utilizes Unity's EditorApplication.hierarchyChanged event to monitor changes in the hierarchy. It provides hooks for handling the addition, removal, renaming, and reparenting of GameObjects.

Here's a breakdown of what the script offers:

GameObject Added: Triggered when a new GameObject is added to the hierarchy.
GameObject Removed: Triggered when an existing GameObject is removed from the hierarchy.
GameObject Renamed: Triggered when a GameObject is renamed.
GameObject Parent Changed: Triggered when a GameObject's parent is changed.

The Script

Below is the complete script for the HierarchyMonitor class:

using UnityEditor;
using UnityEngine;
using System;
using System.Collections.Generic;
using System.Linq;
using Object = UnityEngine.Object;

[InitializeOnLoad]
public static class HierarchyMonitor
{
    private static readonly Dictionary<GameObject, string> _previousNames = new();
    private static readonly Dictionary<GameObject, Transform> _previousParents = new();

    public delegate void GameObjectEventHandler(GameObject gameObject);
    public delegate void GameObjectRenamedEventHandler(GameObject editedObject);
    public delegate void GameObjectParentChangedEventHandler(GameObject gameObject, Transform oldParent, Transform newParent);

    public static event GameObjectEventHandler GameObjectAdded;
    public static event GameObjectEventHandler GameObjectRemoved;
    public static event GameObjectRenamedEventHandler GameObjectRenamed;
    public static event GameObjectParentChangedEventHandler GameObjectParentChanged;

    static HierarchyMonitor()
    {
        EditorApplication.hierarchyChanged += OnHierarchyChanged;

        RefreshPreviousState();
    }

    private static void RefreshPreviousState()
    {
        _previousNames.Clear();
        _previousParents.Clear();

        GameObject[] gameObjects = Object.FindObjectsOfType<GameObject>();

        foreach (GameObject gameObject in gameObjects)
        {
            if (gameObject.hideFlags != HideFlags.None ||
                _previousNames.ContainsKey(gameObject))
            {
                continue;
            }

            _previousNames.Add(gameObject, gameObject.name);
            _previousParents.Add(gameObject, gameObject.transform.parent);
        }
    }

    private static void OnHierarchyChanged()
    {
        GameObject[] currentGameObjects = Object.FindObjectsOfType<GameObject>();

        foreach (GameObject gameObject in currentGameObjects)
        {
            HandleGameObjectAdded(gameObject);
            HandleGameObjectRenamed(gameObject);
            HandleGameObjectParentChanged(gameObject);
        }

        ICollection<GameObject> keys = _previousNames.Keys.ToList();

        foreach (GameObject previousGameObject in keys)
        {
            HandleGameObjectDeleted(currentGameObjects, previousGameObject);
        }

        RefreshPreviousState();
    }

    private static void HandleGameObjectDeleted(GameObject[] currentGameObjects, GameObject previousGameObject)
    {
        if (Array.Exists(currentGameObjects, obj => obj == previousGameObject))
        {
            return;
        }

        Debug.Log($"GameObject removed: {_previousNames[previousGameObject]}");
        GameObjectRemoved?.Invoke(previousGameObject);
        _previousNames.Remove(previousGameObject);
    }

    private static void HandleGameObjectRenamed(GameObject gameObject)
    {
        if (!_previousNames.ContainsKey(gameObject) ||
            gameObject.name == _previousNames[gameObject])
        {
            return;
        }

        Debug.Log($"GameObject renamed from: {_previousNames[gameObject]} to: {gameObject.name}");
        GameObjectRenamed?.Invoke(gameObject);
        _previousNames[gameObject] = gameObject.name;
    }

    private static void HandleGameObjectAdded(GameObject gameObject)
    {
        if (_previousNames.ContainsKey(gameObject))
        {
            return;
        }

        Debug.Log($"GameObject added: {gameObject.name}");
        GameObjectAdded?.Invoke(gameObject);
        _previousNames.Add(gameObject, gameObject.name);
        _previousParents.Add(gameObject, gameObject.transform.parent);
    }

    private static void HandleGameObjectParentChanged(GameObject gameObject)
    {
        Transform currentParent = gameObject.transform.parent;

        if (!_previousParents.ContainsKey(gameObject) ||
            currentParent == _previousParents[gameObject])
        {
            return;
        }

        Debug.Log($"GameObject parent changed: {gameObject.name}");
        GameObjectParentChanged?.Invoke(gameObject, _previousParents[gameObject], currentParent);
        _previousParents[gameObject] = currentParent;
    }
}

How to Use the `HierarchyMonitor`

Create a New Script:
Create a new C# script in your Unity project and name it HierarchyMonitor.cs.
Copy the Script:
Copy the provided HierarchyMonitor script into the new file.
Place the Script in an Editor Folder:
Ensure the script is placed inside an Editor folder in your Unity project. This is necessary as it uses UnityEditor namespace functions which should only be included in the editor code.
Compile the Script:
Unity will automatically compile the script. Once compiled, the HierarchyMonitor will start monitoring changes in the hierarchy.
Subscribe to Events:
You can now subscribe to the GameObjectAdded, GameObjectRemoved, GameObjectRenamed, and GameObjectParentChanged events from any other script to handle these changes as needed.

Example Usage

Here’s an example of how you can subscribe to these events in another script:

using UnityEngine;

public class HierarchyMonitorExample : MonoBehaviour
{
    private void OnEnable()
    {
        HierarchyMonitor.GameObjectAdded += OnGameObjectAdded;
        HierarchyMonitor.GameObjectRemoved += OnGameObjectRemoved;
        HierarchyMonitor.GameObjectRenamed += OnGameObjectRenamed;
        HierarchyMonitor.GameObjectParentChanged += OnGameObjectParentChanged;
    }

    private void OnDisable()
    {
        HierarchyMonitor.GameObjectAdded -= OnGameObjectAdded;
        HierarchyMonitor.GameObjectRemoved -= OnGameObjectRemoved;
        HierarchyMonitor.GameObjectRenamed -= OnGameObjectRenamed;
        HierarchyMonitor.GameObjectParentChanged -= OnGameObjectParentChanged;
    }

    private void OnGameObjectAdded(GameObject gameObject)
    {
        Debug.Log($"Detected GameObject added: {gameObject.name}");
    }

    private void OnGameObjectRemoved(GameObject gameObject)
    {
        Debug.Log($"Detected GameObject removed: {gameObject.name}");
    }

    private void OnGameObjectRenamed(GameObject gameObject)
    {
        Debug.Log($"Detected GameObject renamed: {gameObject.name}");
    }

    private void OnGameObjectParentChanged(GameObject gameObject, Transform oldParent, Transform newParent)
    {
        Debug.Log($"Detected GameObject parent change: {gameObject.name} from {oldParent?.name} to {newParent?.name}");
    }
}

Conclusion

The HierarchyMonitor script is a powerful tool for tracking and handling hierarchy changes in the Unity Editor. By utilizing this script, developers can easily detect and respond to changes in the scene, making it an invaluable asset for complex projects. Happy coding!

For the full source code, you can check out the Gist.

Setting Up Unit Testing in a Unity Project

Dutchskull — Mon, 08 Jul 2024 19:59:19 +0000

If you’re knee-deep in a Unity project and pulling your hair out trying to set up unit testing, you’re not alone. The two biggest challenges are dealing with Assembly Definitions and Editor folders. Here’s a guide to overcome these issues and make your life easier.

The Problem

Unity, in its infinite wisdom, doesn’t allow writing tests on the default Assembly-CSharp and Assembly-CSharp-Editor assemblies. Frustrating, right?

To fix this, you need to add Assembly Definitions for both your game code and editor code. Here’s how:

Game Code:
- Add an Assembly Definition at the root of your project.
- Update the dependencies in the Inspector until there are no compiler errors. Off to the races!
Editor Code:
- Here’s where it gets tricky. In a big project, you’ll have lots of external dependencies and plugins, some with Assembly Definitions, some without.
- Without Assembly Definitions, Unity sees these Editor folders as game code and tries to build them into your final game, which inevitably fails.

The Solution

Create a Top-Level Editor Folder:
- At the top level of your project, create an Editor folder.
- Add an Assembly Definition inside this folder. Name it similarly to your game code Assembly Definition but with a .Editor postfix (or whatever you prefer).
Link Editor Folders:
- For each Editor folder in your project, create an Assembly Definition Reference and link it to the top-level Editor folder Assembly Definition.
- This process can be incredibly tedious in a large project, so here’s a Python script to save you from hours of mind-numbing work:

import os
import json
import yaml

def get_guid_from_meta(meta_file_path):
    with open(meta_file_path, 'r') as meta_file:
        meta_content = yaml.safe_load(meta_file)
    return meta_content.get('guid')

def create_reference_json(editor_path, source_file_name, guid):
    json_content = {
        "reference": "GUID:" + guid
    }
    asmref_file_name = os.path.splitext(source_file_name)[0] + '.asmref'
    json_file_path = os.path.join(editor_path, asmref_file_name)
    with open(json_file_path, 'w') as json_file:
        json.dump(json_content, json_file, indent=4)
    print(f"Created {json_file_path} with GUID reference.")

def copy_file_to_editor_folders(unity_project_path, source_file):
    if not os.path.isdir(unity_project_path):
        print(f"The project path {unity_project_path} does not exist.")
        return

    meta_file_path = source_file + '.meta'
    if not os.path.isfile(meta_file_path):
        print(f"The meta file {meta_file_path} does not exist.")
        return
    guid = get_guid_from_meta(meta_file_path)

    source_file_name = os.path.basename(source_file)

    for root, dirs, files in os.walk(unity_project_path):
        if 'Editor' in dirs:
            editor_path = os.path.join(root, 'Editor')
            asmdef_exists = any(file.endswith('.asmdef') for file in os.listdir(editor_path))

            if not asmdef_exists:
                create_reference_json(editor_path, source_file_name, guid)
            else:
                print(f"A .asmdef file already exists in the folder {editor_path}.")

# Example usage
unity_project_path = r"PATH\TO\ASSETS\FOLDER"
source_file = r"PATH\TO\Editor.asmdef"

copy_file_to_editor_folders(unity_project_path, source_file)

This script requires pyyaml to run:

pip install pyyaml

Set unity_project_path to your Unity project’s assets folder.
Set source_file to the path of your Editor Assembly Definition.

The script will:

Crawl your project for all Editor folders.
Check if an Assembly Definition is present.
Add an Assembly Definition Reference if none exists.

After setting this up, follow the Unity Testing Framework tutorial to start writing tests.

Additional Tips

Consider splitting your code with Assembly Definitions to create logical boundaries and improve maintainability. It might be a pain now, but your future self will thank you!

Happy testing!

How to Create E2E Tests for React Using Playwright

Dutchskull — Thu, 20 Jun 2024 09:22:22 +0000

Setting up end-to-end (E2E) tests for your project has never been easier. With Playwright, you can create robust tests that ensure your application works as expected across different browsers.

Dependencies

To get started, you'll need:

And for the documentation of playwright you can go here

Setting Up Playwright

First, navigate to your React project directory and run:

npm init playwright@latest

Follow the prompts to choose between TypeScript or JavaScript (the default is TypeScript). You'll also need to specify a name for your tests folder. I recommend using a tests/e2e folder at the root of your project.

You’ll be asked if you want to add a GitHub Actions workflow to run tests on CI. If you're using GitHub, this is a handy feature. However, I prefer GitLab and will show you how to set that up instead. Ensure you install Playwright browsers; otherwise, running your tests will be difficult.

After the setup, a configuration file will be generated. You'll need to update a few settings:

Set use > baseURL and webServer > url to use localhost and the correct port for your React project.
Update testDir to point to your e2e tests directory.

Here’s an example configuration:

import { defineConfig, devices } from "@playwright/test";

export default defineConfig({
  testDir: "./tests/e2e",
  fullyParallel: true,
  forbidOnly: !!process.env.CI,
  retries: process.env.CI ? 2 : 0,
  workers: process.env.CI ? 1 : undefined,
  reporter: "html",
  use: {
    baseURL: "http://localhost:5173",
    ignoreHTTPSErrors: true,
    trace: "on-first-retry",
  },

  projects: [
    {
      name: "chromium",
      use: { ...devices["Desktop Chrome"] },
    },
    {
      name: "firefox",
      use: { ...devices["Desktop Firefox"] },
    },
    {
      name: "webkit",
      use: { ...devices["Desktop Safari"] },
    },
  ],

  webServer: {
    command: "npm run dev",
    url: "http://localhost:5173",
    reuseExistingServer: !process.env.CI,
  },
});

GitLab CI Configuration

Add the following task to your .gitlab-ci.yml file to run Playwright tests in your GitLab pipeline:

run_playwright_tests:
  stage: test
  image: mcr.microsoft.com/playwright:v1.44.1-jammy
  script:
    - npx playwright test
    - echo "https://$CI_PROJECT_NAMESPACE.gitlab.io/-/$CI_PROJECT_NAME/-/jobs/$CI_JOB_ID/artifacts/playwright-report/index.html"
  only:
    - merge_requests
  artifacts:
    when: always
    paths:
      - playwright-report
    expire_in: 2 days

Creating Tests Using the Terminal

To create a test using the terminal, run:

npx playwright codegen http://localhost:5173

This command opens a browser and a window that shows the code for the actions you perform in the browser. After clicking through your application to create your test, you can copy the generated code and add it to a WHATEVER.spec.ts file in your tests/e2e folder.

You can run your tests with:

npx playwright test

Creating Tests Using the VS Code Extension

If you prefer not to use the command line, you can use the VS Code Playwright extension.

After installing the extension, navigate to the tests tab in VS Code. Click the Record new button at the bottom. Follow the same steps as in the terminal example, but this time the generated code will be automatically added to your project in a new test file.

With these steps, you’re ready to create and run E2E tests for your React project using Playwright. Happy testing!

How to Kill a Process Binding to a Specific Port in PowerShell

Dutchskull — Thu, 20 Jun 2024 07:56:06 +0000

If you frequently run into issues where a process is binding to a specific port and you need to free that port, PowerShell provides a convenient way to do this. In this blog post, we’ll walk you through how to create a custom PowerShell function that kills the process binding to a specific port.

The Problem

Often, when working with web servers, databases, or other network services, you might encounter the "port already in use" error. This means that a process is currently using the port you are trying to bind your service to. Manually finding and killing this process can be tedious. Automating this task with PowerShell can save you time and hassle.

The Solution

PowerShell has cmdlets that can help you identify and stop processes. We will use Get-NetTCPConnection to find the process ID (PID) using the port and Stop-Process to terminate the process.

Step-by-Step Guide

1. Define the Function

We will create a function called Kill-PortProcess that takes a port number as a parameter and kills the process using that port.

function Kill-PortProcess {
    param (
        [int]$Port
    )
    try {
        $processId = (Get-NetTCPConnection -LocalPort $Port | Select-Object -ExpandProperty OwningProcess)
        if ($processId) {
            Stop-Process -Id $processId -Force
            Write-Host "Process with ID $processId that was using port $Port has been terminated."
        } else {
            Write-Host "No process is using port $Port."
        }
    } catch {
        Write-Host "An error occurred: $_"
    }
}

2. Save the Function

To make this function available in all your PowerShell sessions, save it in your PowerShell profile script. You can edit your profile script by running:

code $PROFILE

Copy and paste the function definition into your profile script and save the file.

3. Use the Function

Now you can use this function in any PowerShell session. For example, to kill the process using port 8080, you would run:

Kill-PortProcess -Port 8080

Conclusion

With this custom PowerShell function, you can quickly and easily free up ports by terminating the processes that are using them. This can be particularly useful for developers and system administrators who frequently run into port conflicts.

Feel free to customize the function to better suit your needs, and happy scripting!

I hope this post helps you manage your ports more effectively. If you have any questions or suggestions, please leave a comment below.

Setting Up Dynamic Environment Variables with Vite and Docker

Dutchskull — Tue, 18 Jun 2024 14:42:02 +0000

Introduction
1. The Problem with Vite and Environment Variables
2. The Concept: Build Once, Inject Later
🔁 How It Works (Visual Recap)
3. Step-by-Step Setup
- Step 1: Define Placeholders in .env.production
- Step 2: Add the Runtime Script (env.sh)
- Step 3: Set Up Docker
- 🐳 Dockerfile – Explained
- 🧩 docker-compose.yml – Explained
4. Advantages and Gotchas
- ✅ Pros
- ⚠️ Gotchas
🔗 Resources
✅ Final Thoughts

Introduction

Stop me if this sounds familiar…

You’ve built a slick Vite frontend, bundled it into a Docker container, and you’re ready to deploy it across environments. Staging. QA. Production. You spin up a few containers with Docker Compose, pass in some environment variables, and… nothing. Your frontend still shows the old values. Or worse, hardcoded ones from build time.

Why? Because Vite bakes your environment variables into the JavaScript at build time. That means by the time your app hits the container, those variables are already locked in. If you want to change them, you’ve got to rebuild your app from scratch—for each environment. Which defeats the entire point of using Docker in the first place.

Here's the fix:
In this guide, you’ll learn how to build your Vite app once with environment placeholders, and inject the actual values at runtime using a simple script inside Docker. No more rebuilding for every deploy. Just plug in your config at startup, and let your container do the rest.

1. The Problem with Vite and Environment Variables

Vite makes development fast—but once you hit deployment, it locks you into a limitation that trips up a lot of devs:

Environment variables are statically replaced at build time, not dynamically read at runtime.

That means when you run npm run build, Vite crawls through your code and literally replaces any reference like import.meta.env.VITE_API_URL with the value in .env.production at that moment. It becomes a hardcoded string in your final JS bundle.

If you want different values for staging or production? You’re stuck rebuilding your app for each environment. That’s time-consuming, error-prone, and kills the point of Docker’s "build once, run anywhere" philosophy.

2. The Concept: Build Once, Inject Later

Here’s the idea: instead of hardcoding real values into your build, you bake in placeholders—clearly identifiable markers like PREFIX_API_URL.

Then, when the container starts up, a small shell script scans the final JavaScript files and swaps those placeholders for actual values from your environment—using plain old sed. Just before Nginx serves the files.

Why this works:

Vite doesn’t know your values at build time—it just drops in what you give it.
At runtime, Docker does know your values, and you can use them to patch the final files.
You still get a fully static, cacheable frontend bundle—but with runtime flexibility.

And no, it’s not a hack—it’s a pragmatic workaround that’s safe, production-ready, and used in many real-world pipelines.

🔁 How It Works (Visual Recap)

Here’s what’s happening behind the scenes:

Build phase

Vite replaces env references with placeholder strings like "PREFIX_API_URL" in your compiled JS.

Runtime phase

Your Docker container starts with the real environment variables (e.g. PREFIX_API_URL=https://api.myapp.com).
A shell script replaces every placeholder in the final JS/HTML files.
Nginx serves the updated files.

3. Step-by-Step Setup

Let’s walk through how to set this up from scratch.

Step 1: Define Placeholders in `.env.production`

Create a .env.production file in the root of your project. The .env.production file will be used by vite build for its environment variables. Inside your project, add this line to .env.production:

VITE_API_URL=PREFIX_API_URL

The value PREFIX_API_URL is a placeholder that Vite will statically bake into your code. It doesn’t need to be real—just something unique and easy to find later.

Step 2: Add the Runtime Script (`env.sh`)

This is the important part

Drop this env.sh script into your project root. Make sure it’s executable (chmod +x env.sh) and converted to Unix line endings (dos2unix env.sh if needed). If you don't want to do this every time you can also add those commands to your Dockerfile.

Step 3: Set Up Docker

🐳 Dockerfile – Explained

Here’s a Dockerfile that builds your Vite app and prepares it for runtime replacement:

# Step 1: Build the app using Node
FROM node:23-alpine AS builder

WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Step 2: Use a lightweight Nginx container to serve the files
FROM nginx:alpine

# Copy Nginx config if you have custom routing
COPY ./nginx.conf /etc/nginx/nginx.conf

# Copy the built app from the builder stage
COPY --from=builder /app/dist /var/www/html/

# Copy the runtime injection script into the container
COPY env.sh /docker-entrypoint.d/env.sh
RUN dos2unix /docker-entrypoint.d/env.sh
RUN chmod +x /docker-entrypoint.d/env.sh

# Let Docker run your script before starting Nginx
ENTRYPOINT ["/docker-entrypoint.sh"]
CMD ["nginx", "-g", "daemon off;"]

🧩 docker-compose.yml – Explained

This Compose config shows how to inject the real values during container startup:

services:
  app:
    image: app:latest
    build:
      context: app
    ports:
      - "8080:80"
    environment:
      # Where your built files live in the container
      ASSET_DIR: /var/www/html

      # Prefix used for placeholder detection
      APP_PREFIX: PREFIX_

      # Real values for your frontend to consume
      PREFIX_API_URL: "https://api.myapp.com"

Key things happening here:

ASSET_DIR tells env.sh where to search for files.
APP_PREFIX ensures we only replace the values we want.
PREFIX_API_URL is the real value your app needs—matched to the placeholder in .env.production.

4. Advantages and Gotchas

✅ Pros

Single build for all environments
Build once. Deploy many times.
Static file friendly
Keeps your assets cacheable and CDN-ready.
Framework agnostic
Works with any static frontend—not just Vite.

⚠️ Gotchas

Pick a unique prefix
Avoid accidental replacements. PREFIX_ is a good default.
Beware of quotes and special characters
Escape them properly if needed in shell scripts.

🔗 Resources

📂 GitHub Repo: Dutchskull/Vite-Dynamic-Environment-Variables
🧰 Shell script: env.sh

✅ Final Thoughts

This setup gives you flexibility without sacrificing speed or simplicity. You keep your frontend static, lightweight, and easy to cache—while still injecting environment-specific config at runtime.

It’s a clean bridge between how Vite works and how Docker deployments need to work.

You no longer have to rebuild for every little config change. Just build once, inject on start, and move on.

Enhance Your Development with Multi-Repo Support in Dotnet Aspire

Dutchskull — Sat, 15 Jun 2024 19:24:17 +0000

.NET Aspire is renowned for its robust support for monolithic repositories, allowing developers to manage large codebases efficiently. However, managing multiple repositories, or poly repos, can be challenging. Enter Aspire.PolyRepo, a .NET Aspire package designed to bridge this gap and provide seamless multi-repo support.

Introducing Aspire.PolyRepo

Aspire.PolyRepo simplifies the process of cloning and managing Git repositories within your .NET Aspire applications. This package allows you to configure and integrate Git repositories effortlessly, streamlining your cloud-native development workflow.

Key Features

Direct Git Integration: Clone repositories directly into your .NET Aspire application.
Flexible Configuration: Customize repository URL, name, target path, default branch, and project path.
Seamless Integration: Easy setup with .NET Aspire App Host.

Installation

To install the Aspire.PolyRepo package, use the .NET CLI. Run the following command in your terminal:

dotnet add package Dutchskull.Aspire.PolyRepo

Usage

Here's a step-by-step guide to using Aspire.PolyRepo in your .NET Aspire application:

Step 1: Add a Repository Resource

First, add the necessary configuration to your App Host project. Below is an example of how to configure a Git repository:

var builder = DistributedApplication.CreateBuilder(args);

var repository = builder.AddRepository(
    "repository",
    "https://github.com/Dutchskull/Aspire-Git.git",
    c => c.WithDefaultBranch("feature/rename_and_new_api")
        .WithTargetPath("../../repos"));

Step 2: Add Projects from the Repository

You can add various types of projects from the repository. Here’s how you can add a .NET project:

var dotnetProject = builder
    .AddProjectFromRepository("dotnetProject", repository,
        "src/Dutchskull.Aspire.PolyRepo.Web/Dutchskull.Aspire.PolyRepo.Web.csproj")
    .WithReference(cache)
    .WithReference(apiService);

Aspire.PolyRepo also supports adding npm and node applications. These methods share the initial parameters with AddProjectFromRepository, but their additional parameters are specific to npm and node configurations:

var reactProject = builder
    .AddNpmAppFromRepository("reactProject", repository, "src/Dutchskull.Aspire.PolyRepo.React")
    .WithReference(cache)
    .WithReference(apiService)
    .WithHttpEndpoint(3000);

var nodeProject = builder
    .AddNodeAppFromRepository("nodeProject", repository, "src/Dutchskull.Aspire.PolyRepo.Node")
    .WithReference(cache)
    .WithReference(apiService)
    .WithHttpEndpoint(54622);

Step 3: Navigate to Your App Host Project Directory

Open your terminal and navigate to the directory of your App Host project.

Step 4: Run the Application

Use the .NET CLI or Visual Studio 2022 to run your application:

dotnet run

This configuration clones the specified Git repository into your application, enabling seamless integration and development across multiple projects.

Recap

Aspire.PolyRepo is the solution for developers looking to manage multiple repositories within their .NET Aspire applications effortlessly. By following the simple steps outlined above, you can configure and run your applications, leveraging the power of poly repo support. With its straightforward setup and robust feature set, Aspire.PolyRepo ensures that managing multiple repositories becomes a hassle-free part of your development workflow.

Check out the Aspire.PolyRepo source here

Building executable as user for distribution from a progressive web app

Dutchskull — Tue, 06 Jul 2021 14:06:32 +0000

I was working on a project for graduation called Roots, and I needed a way of exporting a web experience to an executable. I never expected this to be such a difficult thing to find information on. Granted, there are not a lot of use cases for this. Since I could not find a good way of exporting a web experience to an executable, I embarked on a quest to figure this out for myself.

Why an executable?

Some might wonder: "Why would you want to export an executable from the web?". In my case, I needed this for my graduation project Roots. Roots is a 2D narrative game engine in the browser. Here are the pros to giving the option to create a executable to your users.

Distribution

The main thing with Roots was that it has to be simple, so everybody with a browser can use it. And letting users try to host their projects online as a web app is not what I would call accessible for anyone. I think you know where I am going with this. I wanted a way that people would be able to distribute their projects on their own.

Feel

I also surveyed gamers about web games and installed games. One thing that came back multiple times was that they had the feeling that games hosted on the web were of lesser quality than installed games. Something about being able to have the game physically installed feels more premium.

Offline

One of the requirements was also that people should be able to use Roots offline. So it had to be installable, and work offline. Therefore, I had to figure out how to get an executable from a web app.

After this tutorial you will have touched a JavaScript compiler, Electron, C# and PWA. But that is enough of an introduction, for now, let’s take a closer look at how I worked it out.

Concept

The concept I will discuss is pretty simple. But getting all the parts together and work nicely with each other was the hard part. And in the end, the user should be able to use it. Otherwise, it would not add value.

Engine

One of the nice parts of working with web technology is that you will have to create the rendering engine only once. This is important because you want to keep the experience the same between the game editor(PWA) and the final executable(App).

Progressive web app

The best way too handle files in my opion is making use the Chrome File System API. You can use this when you have a https site or PWA. This will make the experience of for exporting a executable more like a normal installed app.

Builder / Protocol

There are two ways to do this part. For now, I will only explain how to do the builder way. The builder is an executable that you can make that will get all the resources needed to build your project on a user's computer. Like an installer that does not permanently install unwanted software on the user's computer.

I'm figuring out how to do the protocol way and will update if I found a way of doing so.

App

The app is the result of what comes out of the builder. This will be a single executable Electron app that can be shared. Because we are using Electron, it makes it possible to export the project to the user's current operating system.

Requirements

If you want to follow along with the implementation that I will be sharing down here, this is what you need to be familiar with.

NodeJS
ReactJS (or any other front-end framework)
Electron Forge (or any Electron CLI or template)
Yarn (or NPM)
Babel (or any other JavaScript compiler)
Chrome File System API
Chrome
C# (or any other language that compiles to a binary or executable)

The best experience I could create was in Chrome. This is because of their excellent Chrome File System API. It is also doable with other browsers, but the user experience will be a lot less pollished then when you use Chrome.

I like to use yarn to install and manage my decencies, but if you want to use NPM you free to do so.

Note: You can use different libraries to get the same result. But after a lot of trail and error, this what I came up with. If you know how to do this in other libraries, please share it in the comments below.

Engine

If you just want to check out the code, you can do that here → Git

The main thing with the engine is that you need to make a component with your front end framework that will accept data. In my case this is JSON, images and audio files. These have to be read and then displayed. When you have a working engine, you have to be able to share it with the rest of your project. This is when you have to use a JavaScript compiler to make it as compatible with other code as possible. Then you can publish it too NPM and use it with other projects. Now that we have defined what we have to do, let me show you how I did it.

Let's start with the backbone of your experience, the engine. Create a folder with the name of your engine and cd into it.

 > mkdir engine
 > cd ./engine

Then we can create a React app in this folder using NPX and React's default template.

 > npx create-react-app .

When this is done, we will need to set up babel. This is a JavaScript compiler that will make sure that we can distribute our engine between the web app and the app. Make sure you add them as a dev dependency.

 > yarn add --dev @babel/cli @babel/core @babel/preset-env @babel/preset-react core-js

Now we have to create a babel.config.json in the root folder of our project. And this is the config you will add.

{"presets": ["@babel/preset-env", "@babel/preset-react"]}

Now we have to configure the package.json with the build command for babel.

"build": "del /s /q dist && babel src/Engine --out-dir dist --copy-files"

There is some configuration you can do here. You can remove the /s and /q from the del command if you want to be asked if you are sure you want to rebuild. I would keep dist unchanged for the del and babel commands because this is a default. You can change the src/Engine however you want to call the folder where you have the source of your engine. But make sure it is a separate folder from the App.js and index.js.

The last thing to do in the package.json is setting the main, module, and type. This will also depend on how you export your library. I like to have one index.js that exports all.

"main": "dist/index.js",
"module": "dist/index.js",
"type": "module",

How you are going to build your engine is up to you. But for example, this is how I made mine.

engine/src/Engine/Engine.js

import  *  as  React  from  "react";
import  "core-js"; 

const  Engine = ({ data }) => {
    return (<div  className="App">
                <h1>{data.title}</h1>
                {data.images.map(image  =>  <img  src={image}  alt=""  width={300}  key={image}  />)}
            </div>);
};

export  default  Engine;

Make sure to import core-js here. Otherwise, you will have some dependency problems with Electron later on.

engine/src/App.js

import  Engine  from  "./engine";
import  projectData  from  "./projectData";

const  App = () => {
    const  preProcessor = {
        ...projectData,
        images: [...projectData.images.map(i  =>  `/img/${i}`)]
    };

    return (<Engine  data={preProcessor}  />);
};

export  default  App;

This App.js is an example that you can have next to your engine library, with the purpose of easy testing without having to switch between the web app or app project. You can just use yarn start and work on the engine like a normal React project.

Now to be able to distribute our engine to the other parts of our project we have to publish this library to NPM.

yarn publish

Yarn will ask you to log in if you haven't already, and it will ask you to give a version number when publishing. After you have done this, you have successfully set up the engine project we are going to use.

PWA (progressive web app)

If you just want to check out the code, you can do that here → Git

This is where you would make the tools that your end user can use to create a presentation, game or what ever you need for your project. Again, you can do this using any front end framework that you want, I will be using React here. There is one key part that is important here. And that is the of the Chrome File System API. This will give your user the best experience when working with files. This is also important because we are going to need this to deliver the content files and the builder executable with it. Let me show you how I did this.

For the web app, you can follow the first two steps from the engine. So make a folder named web app, and create a React app.

There are three parts to the web app that I will explain. First is how to manage a project with Chrome File System API and second how the engine will be used with the web app. Finally, we will return the builder to the user. This is quite a lot, so bear with me.

If you want to read up on the Chrome File System API you can do so here

web app/scr/App.js

import { useEffect, useState } from "react";
import Engine from "Engine";

const App = () => {
  const [project, setProject] = useState();

  const [projectData, setProjectData] = useState({
    title: "This is your project",
    images: []
  });

  const openProject = () => {
        window
            .showDirectoryPicker()
            .then((directory) => {
                setProject(directory);
                return directory.values();
            })
            .then(async (fileHandles) => {
                let projectData = undefined;
                let imageDirectory = undefined;
                for await (const entry of fileHandles) {
                    if (entry.name === "projectData.json") projectData = entry;
                    else if (entry.name === "img") imageDirectory = entry;
                }

                if (!projectData) return;

                projectData
                    .getFile()
                    .then((file) => file.text())
                    .then((json) => JSON.parse(json))
                    .then(async (data) => {
                        const imageHandlers = await imageDirectory.values();

                        const images = [];
                        for await (const entry of imageHandlers) {
                          if (!data.images.includes(entry.name)) continue;

                          images.push(entry);
                        }

                        const newData = {
                            ...data,
                            images: [...images],
                        };

                        setProjectData(newData);
                    });
            });
    };

  const loadImages = () => {
    if (!project) {
      alert("No project folder opened")
      return;
    }

    window.showOpenFilePicker(imagePickerOptions)
      .then(images => {
        setProjectData({
          ...projectData,
          images: [
            ...projectData.images,
            ...images]
        });
      });
  };

  const saveProject = () => {
    if (!project) {
      alert("No project folder opened")
      return;
    }

    project.getFileHandle('projectData.json', { create: true })
      .then(newFile => 
          writeFile(newFile, JSON.stringify({
            ...projectData,
            images: [...new Set(projectData.images.map(i => i.name))]
          }
    )));

    project.getDirectoryHandle('img', { create: true })
      .then((imageFolder) => {
        projectData.images.forEach((image) => {
          imageFolder.getFileHandle(image.name, { create: true })
            .then(newFile => {
              image.getFile()
                .then(file => writeFile(newFile, file));
            });
        });
      })
  };

  return (
    <div className="App" >
      <button onClick={openProject}>Open project</button>
      <button onClick={loadImages}>Load image</button>
      <button onClick={saveProject}>Save project</button>
      <h1>{project ? `${project.name} opened` : "No project opened yet"}</h1>
      {
        projectData.images.length > 0 &&
        projectData.images.map(({ name }) => {
          return <h2 key={name}>{`${name} opened`}</h2>
        })
      }
    </div >
  );
}

export default App;

There is a lot to unpack here. But it's easier than you might think.

openProject will call window.showDirectoryPicker which will open a directory picker. Its default behavior is to register this folder as a new project. But if it finds a projectData.json it will try and load all the data so you can keep working on your project.

loadImages is like openProject, but it will call window.showFilePicker and then the user can load an image.

saveProject will save all the files that are used in the project to the project folder. Using the getFileHandle and getDirectoryHandle you can create directories and files in the project folder.

And in the render function, there is some extra markup to show what's loaded in the project.

writeFile and writeURLToFile you can find those implementations here. All functions from the Chrome File System API are async and are to be awaited. If you want to publish the web app you will have to register an SSL certificate before you can use it.

Engine

Now you can install your engine that you have created and published earlier on.

yarn add <-- Write the name of your engine here

And then you can implement the engine into the web editor.

web app/scr/App.js

...

const [preProcessor, setPreProcessor] = useState();

useEffect(() => {
  Promise.all(projectData.images.map(i => i.getFile()
    .then(f => URL.createObjectURL(f))))
    .then(data => {
      setPreProcessor({
        ...projectData,
        images: [...data]
      });
    });
}, [projectData]);

return (
  <div className="App" >
    {...}
    {preProcessor && <Engine data={preProcessor} />}
  </div >
);

Like I did in the example from the engine, I created a pre-process that takes the file handlers and creates object URLs for them, so the engine can render them. Because this is an asynchronous process, we can expect preProcessor to be empty. So we have to check for this in the render.

Builder

Now let's see how we can share the builder with the user.

web app/scr/App.js

...

const buildProject = () => {
    if (!project) {
      alert("No project folder opened")
      return;
    }

    project.getFileHandle('builder.exe', { create: true })
      .then(newFile => writeURLToFile(newFile, `${window.location.hostname}/<-- Add the path to where your builder.exe is  -->`));
};

return (
  <div className="App" >
    {...}
    <button onClick={buildProject}>Build project</button>
    {...}
  </div >
);

...

Because we have access to the project folder through the Chrome File System API it's really easy to download something to that folder. Here, I am using the writeURLToFile function to write a file in the public folder to the user’s project folder. Currently, we don't have the builder ready, but it will be added later when we have finished the builder.

We can't call this from the browser because of security. That is one of the downfalls. You have to instruct the user to go to the folder and execute the builder. There is an alternative way where you can take advantage of registering a protocol and have the user only install the builder once. In this case, the next time they want to build, you can access the builder through a URL.

That is how to set up your web app and preview and set up a project that can be built later with the builder.

App (Electron template)

If you just want to check out the code, you can do that here → Git

This is where we are setting up what the final exported app will look like. The steps that we are going to take here are create a template that uses the engine that you have made, then we will set up a module bundler to get access to the content that the engine will need to render the user's experience. And then we will push all of this to git so the builder wich we will work on after this can access this template real easy. Let's set all this up now.

For setting up the base for your Electron app template, you can follow the instructions here.

Now we install the dependencies. file-loader is needed to be able to pack the images in the Electron app.

yarn add --dev file-loader

You must also add the engine dependency here. So when we will build it later, we don't need to add them.

Now we have to change the webpack.renderer.config.js so that webpack will use the file loader to access the images when the Electron app is built. This is what the config should look like.

const rules = require('./webpack.rules');

rules.push({
  test: /\.css$/,
  use: [{ loader: 'style-loader' }, { loader: 'css-loader' }],
});

rules.push({
  test: /\.(png|jpe?g|gif)$/i,
  use: [
    {
      loader: 'file-loader',
      options: {
        name: 'img/[name].[ext]',
        publicPath: '../.'
      }
    },
  ],
});

module.exports = {
  module: {
    rules,
  },
};

Electron does not like you to access public files directly. That is why we have to add a local protocol to Electron. This can be done in /src/main.js. First import session here const { app, BrowserWindow } = require('electron');. Then you can add the protocol here.

...

const createWindow = () => {
  session.defaultSession.protocol.registerFileProtocol('static', (request, callback) => {
    const fileUrl = request.url.replace('static://', '');
    const filePath = path.join(app.getAppPath(), '.webpack/renderer', fileUrl);
    callback(filePath);
});

const mainWindow = new BrowserWindow({
...

You can change static to whatever you like. It is just the name of your protocol.

Now that everything is set up we can implement the engine in Electron.

/scr/app.jsx

import * as React from "react";
import * as ReactDOM from "react-dom";
import Engine from "Engine";
import projectData from "./projectData";

const importAll = (resource) => resource.keys().map(resource);

importAll(require.context("./img", false, /\.(png|jpe?g|gif)$/));

const preProcessor = {
    ...projectData,
    images: [...projectData.images.map((i) => `static://img/${i}`)],
};

ReactDOM.render(
    <Engine data={preProcessor} />,
    document.getElementById("root")
);

Before rendering, we need to tell React to import all the resources that webpack has built. Namely, all the images that are in the project.

Here we are doing pretty much the same as in the example from the engine. The only difference is that we are adding the static:// before the img/. This way we can access the image files.

Now you can test if the app works by adding an img folder to src and a projectData.json. Then you can run yarn start first to see if it works. After that, you can verify if the build works by running yarn make and going to the out folder after it's finished and running the build.

You could also look at Electron Forge yourself. You can configure a lot, like icons and start-up behaviors, but that is all up to you.

If everything works, we need to push all of this to git. This is important! Because after this we want to be able to get this template through the builder and git has a nice feature that we can exploit for this.

Builder

If you just want to check out the code, you can do that here → Git

The builder does a couple of things. Firstly, it gets all the resources that we need to create a build. So in this case it will download NodeJs and the Electron template. Because we can't be sure that the user has NodeJs we download it for them. And the nice thing is you can execute NodeJs in place. And the Electron template can also easily be downloaded using the git zipball feature. These will be placed alongside of the project, so the builder can have access to the user's project content. This will be moved to the Electron template. And then we can use NodeJs to execute the install dependencies command and the build command of the Electron template. And then after a while you have a Electron app that the user can distribute. And down here is how to do this.

The builder will be written in C#. And this has no other reason than that I am very comfortable creating executables with it. This should also be possible in NodeJS if you are using pkg or nexe. On top of that C# can be compiled for Linux, Mac, and Windows. So you can distribute this to multiple platforms.

For the sake of the example, I created a console application that will demonstrate what the steps are. But for user experience, it could also be done as a windows form.

private const string BUILDER_TOOLS = "BuilderTools";
private const string NODE_JS = "NodeJs";
// This could be any NodeJS version you needed. Make sure it is the zip version.
private const string NODE_JS_URL = "https://nodejs.org/dist/v14.16.1/node-v14.16.1-win-x64.zip";

private const string APP_TEMPLATE = "AppTemplate";
private const string APP = "App";
private const string APP_TEMPLATE_GIT = "https://api.github.com/repos/<-- GIT USERNAME -->/<-- GIT REPO NAME -->/zipball";

private const string PROJECT_NAME = "Project";

These are the config options for the builder. You can change or edit anything to your liking. This is only to be more organized. Notice APP_TEMPLATE_GIT, this is why we needed to publish the app template to git. Because you can't be sure that the user has git or NPM installed, you have to get the app template another way. This is where zipball comes in handy. Now we can just download the zip to the user, and we don't need to install anything extra on their machine.

/* Setting up NodeJs */
Console.WriteLine("Downloading NodeJs");

if (!Directory.Exists(BUILDER_TOOLS))
{
    WebClient webClient = new();
    webClient.DownloadFile(NODE_JS_URL, $".\\{BUILDER_TOOLS}.zip");
    Console.WriteLine("Downloaded NodeJs");

    Console.WriteLine("Extracting NodeJs");
    ZipFile.ExtractToDirectory($".\\{BUILDER_TOOLS}.zip", BUILDER_TOOLS, true);

    // Renaming the folder in the builder tools so it’s easier accessible
    DirectoryInfo node = new($".\\{BUILDER_TOOLS}");
    if (!Directory.Exists($"{node.FullName}\\{NODE_JS}"))
    {
        Directory.Move(node.GetDirectories()[0].FullName, $"{node.FullName}\\{NODE_JS}");
        Directory.Delete(node.GetDirectories()[0].FullName);
    }

    File.Delete($".\\{BUILDER_TOOLS}.zip");
}
Console.WriteLine("Extracted NodeJs");

/* Setting up App template */
Console.WriteLine("Downloading App template");

if (!Directory.Exists(APP_TEMPLATE))
{
    using WebClient client = new();
    client.Headers.Add("user-agent", "Anything");
    client.DownloadFile(APP_TEMPLATE_GIT, $".\\{APP_TEMPLATE}.zip");
    Console.WriteLine("Downloaded App template");

    Console.WriteLine("Extracting App template");
    ZipFile.ExtractToDirectory($"{APP_TEMPLATE}.zip", APP_TEMPLATE, true);

    DirectoryInfo app = new($".\\{APP_TEMPLATE}");
    if (!Directory.Exists($"{app.FullName}\\{APP}"))
    {
        Directory.Move(app.GetDirectories()[0].FullName, $"{app.FullName}\\{APP}");
        Directory.Delete(app.GetDirectories()[0].FullName);
    }

    //Clean up
    File.Delete($"{APP_TEMPLATE}.zip");
}
Console.WriteLine("Extracted App template");

These two parts are doing pretty much the same thing. They are getting NodeJS and the git repo and extracting them to the project folder. Always clean up and remove the zip files after you are done extracting.

File.WriteAllBytes(@"C:\NodeJS.zip", YourProjectName.Properties.Resources.NodeJS);

This is one way of doing it. Because you could also embed everything as a resource. And then your code would be simpler. But the initial download would be bigger. But just if your curious, you can find how to load a resource in C# here. And this is how you would write it to disk.

/* Move the project files to the app template and overwrite if they already exist */
Console.WriteLine("Setup App template");

if (!Directory.Exists($".\\{APP_TEMPLATE}\\{APP}\\src\\img"))
    Directory.CreateDirectory($".\\{APP_TEMPLATE}\\{APP}\\src\\img");

CopyFilesRecursively(".\\img", $".\\{APP_TEMPLATE}\\{APP}\\src\\img");

if (File.Exists($".\\{APP_TEMPLATE}\\{APP}\\src\\projectData.json"))
    File.Delete($".\\{APP_TEMPLATE}\\{APP}\\src\\projectData.json");

File.Copy(".\\projectData.json", $".\\{APP_TEMPLATE}\\{APP}\\src\\projectData.json");
Console.WriteLine("Setup done App template");

// This is a utility function you can place outside the main function
private static void CopyFilesRecursively(string sourcePath, string targetPath)
{
    foreach (string dirPath in Directory.GetDirectories(sourcePath, "*", SearchOption.AllDirectories))
        Directory.CreateDirectory(dirPath.Replace(sourcePath, targetPath));

    foreach (string newPath in Directory.GetFiles(sourcePath, "*.*", SearchOption.AllDirectories))
        File.Copy(newPath, newPath.Replace(sourcePath, targetPath), true);
}

Because the builder executable is going to live in the same folder as where the project is, we can move the project files to the app template. If they are there already we want to overwrite them.

/* Setup the package.json of the app */
Console.WriteLine("Configure App template");

string path = $".\\{APP_TEMPLATE}\\{APP}\\package.json";

string json = File.ReadAllText(path);
JObject package = JObject.Parse(json);

SaveJsonKeyEdit(package, "author", "dutchskull");
SaveJsonKeyEdit(package, "description", "An exported executable from the web");
SaveJsonKeyEdit(package, "name", PROJECT_NAME);

File.WriteAllText(path, package.ToString());
Console.WriteLine("Configure done App template");

// This is a utility function you can place outside the main function            
private static void SaveJsonKeyEdit(JObject package, string key, object value)
{
    if (package.ContainsKey(key))
        package[key] = value.ToString();
    else
        package.Add(key, value.ToString());
}

At this point, we can do some configuration based on the project itself. If you add some settings for the user to change in the web app, like icons, name, description, and author, you can configure them back into the app template here. You will need to add Newtonsoft.Json to your C# project. This can be done by running this command in the terminal NuGet install Newtonsoft.Json.

/* The building step */
Console.WriteLine("Building App template");

CommandExecuter.ExecuteCommand($"cd .\\{APP_TEMPLATE}\\{APP} && .\\..\\..\\{BUILDER_TOOLS}\\{NODE_JS}\\npm.cmd i");

CommandExecuter.ExecuteCommand($"cd .\\{APP_TEMPLATE}\\{APP}\\ && .\\..\\..\\{BUILDER_TOOLS}\\{NODE_JS}\\npm.cmd run make");
Console.WriteLine("Build App template");

Now you will run the commands to install all of the dependencies of the app template. I needed to create a custom class to run these commands without having crashes. But I will not go into detail on those since they are only here for support. You can download those here → CommandExecutor and CommandOutput.

/* Move the build to the root of the project */
DirectoryInfo buildOutputPath = new($".\\{APP_TEMPLATE}\\{APP}\\out\\make\\squirrel.windows\\x64\\");

if (File.Exists($"./{PROJECT_NAME}.exe"))
    File.Delete($"./{PROJECT_NAME}.exe");

File.Move(buildOutputPath.GetFiles().Where(file => file.Name.Contains(".exe")).FirstOrDefault().FullName, $"./{PROJECT_NAME}.exe");

if (File.Exists($"{PROJECT_NAME}.exe"))
    Process.Start("explorer.exe", $"{ PROJECT_NAME}.exe");

After the build is done, we can grab the executable and move it to the root project folder where the user can grab it. We can also auto-run the project when it is done building. This way the user knows it works.

Now that we have written the builder, we have to make an executable that we can add to the web app. This part was also difficult. I wanted to create a portable executable because it is easier to share one file than multiple. So I read the documentation and this is what you need to do.

  <PropertyGroup>
      <OutputType>Exe</OutputType>
      <TargetFramework>net5.0</TargetFramework>
      <PublishSingleFile>true</PublishSingleFile>
      <SelfContained>true</SelfContained>
      <RuntimeIdentifier>win-x64</RuntimeIdentifier>
      <PublishTrimmed>true</PublishTrimmed>
      <PublishReadyToRun>true</PublishReadyToRun>
      <IncludeAllContentForSelfExtract>true</IncludeAllContentForSelfExtract>
      <DebugType>embedded</DebugType>
  </PropertyGroup>

You need to edit the project XML file and put this property group instead of the property group that is already there. With all of these settings, you can go to publish like illustrated down below.

Now that we have a portable executable that will build an Electron app for our users, we have to add it to the web app. So in the web app project, you can now add the new build builder to public/builder.exe.

And that's it. Now you have a fully working build system for a web app.

Final thoughts

Phew, that was a lot. It takes almost half a day to get everything set up. But in the end, you will have a system that can build an app from a web app and that a user can use and distribute. There are still some user experience quirks that have to be ironed out. Like letting the user install a builder once and use a protocol to build their experience after that. The way the builder is delivered to the user, by choosing how to package NodeJS and the app template, could also be improved. But none of these cases are breaking the core concept.

This is my first time writing a blog post like this, so I would love to get some feedback for next time so I can keep sharing experiments like this.

DEV Community: Dutchskull

Run Unity3D as a First‑Class Service with .NET Aspire (Aspire.Unity experimental)

Why bring Unity into Aspire?

Quick install

Minimal example

Advanced usage

Configuration: Aspire config inside Unity

Example scenarios

Roadmap

Try it

Adjusting Scroll Speed on Linux: A Quick Guide

Step 1: Install Required Tools

Step 2: Measure Touchpad Size

Step 3: Calculate Desired Scroll Speed

Step 4: Copy Output

Step 5: Edit Configuration File

Step 6: Update and Reload

Final Step: Reboot

Resetting to Default

Enabling Mixed Content in Blazor Apps on Android: A Step-by-Step Guide

Problem Statement

Solution Overview

Step 1: Modify the BlazorWebView Configuration

Update MainPage.xaml

Implement the Event Handler in MainPage.xaml.cs

Step 2: Update the Android Manifest

Update AndroidManifest.xml

Step 3: Test the Implementation

Conclusion

Building a Complex Form with React Hook Form and Yup

Overview of the Form

Key Components

1. Form Component

2. BookInputRow Component

3. Validation Schema

How to Set Up the Project

Conclusion

Monitoring GameObject Changes in the Unity editor hierarchy

Introduction

Overview of HierarchyMonitor

The Script

How to Use the HierarchyMonitor

Example Usage

Conclusion

Setting Up Unit Testing in a Unity Project

The Problem

The Solution

Additional Tips

How to Create E2E Tests for React Using Playwright

Dependencies

Setting Up Playwright

GitLab CI Configuration

Creating Tests Using the Terminal

Creating Tests Using the VS Code Extension

How to Kill a Process Binding to a Specific Port in PowerShell

The Problem

The Solution

Step-by-Step Guide

1. Define the Function

2. Save the Function

3. Use the Function

Conclusion

Setting Up Dynamic Environment Variables with Vite and Docker

Introduction

1. The Problem with Vite and Environment Variables

2. The Concept: Build Once, Inject Later

🔁 How It Works (Visual Recap)

3. Step-by-Step Setup

Step 1: Define Placeholders in .env.production

Step 2: Add the Runtime Script (env.sh)

Step 3: Set Up Docker

🐳 Dockerfile – Explained

🧩 docker-compose.yml – Explained

4. Advantages and Gotchas

✅ Pros

⚠️ Gotchas

🔗 Resources

✅ Final Thoughts

Enhance Your Development with Multi-Repo Support in Dotnet Aspire

Introducing Aspire.PolyRepo

Update `MainPage.xaml`

Implement the Event Handler in `MainPage.xaml.cs`

Update `AndroidManifest.xml`

Overview of `HierarchyMonitor`

How to Use the `HierarchyMonitor`

Step 1: Define Placeholders in `.env.production`

Step 2: Add the Runtime Script (`env.sh`)