I am using AMP Release “Deimos” v2.7 (Build 08/03/2026) and I am experiencing a persistent issue with the RAGE:MP C# bridge in a Docker container (image: cubecoders/ampbase:debian).
When C# is enabled, the server fails to start with these errors:
“Process terminated. Couldn’t find a valid ICU package installed on the system.”
“This is not a published, standalone application and we are unable to locate the .NET Core SDK.”
Environment & Attempts:
I have tried adding libicu-dev and dotnet-sdk-8.0 to the “Container Packages” list, but the libraries don’t seem to persist or aren’t recognized after a restart.
Manual installations via docker exec work until the instance is restarted/re-created by AMP.
How can I ensure these .NET dependencies are persistently available within the “Deimos” Docker deployment for RAGE:MP?
Reproduction Steps
Create a new RAGE:MP instance using the standard Docker image (ampbase:debian).
Enable C# support in the instance configuration settings.
Start the instance and observe the console log failing during the C# bridge initialization.
Attempt to install libicu-dev or set environment variables, which are then lost upon container restart.
This package is not available in the default Debian repos so won’t be installed.
libicu-dev should install fine (tested here on an instance). Tho do you actually need the dev package? libicu76 is in the image by default.
To get the .NET SDK into the instance, the template will need to be updated to install it locally and set DOTNET_ROOT.
I note the default RAGE installation has a dotnet dir with Windows runtime libs. Could the SDK download be on top of that or should it be kept separate?
This page suggests that the SDK to be installed and used should match the version in the dotnet/runtime dir that is installed with the server, which is 3.1.3 on a fresh install
Actually, can just bypass the issue by setting DOTNET_SYSTEM_GLOBALIZATION_INVARIANT to 1. Assume globalisation support is not really needed? I’ve set that on other templates without issue.
Thank you for the update. Since you are aware that I am running AMP Release “Deimos” v2.7, I have a specific follow-up regarding the UI and the .NET configuration:
Locating Settings: Despite being on v2.7, I am unable to find the “Environment Variables” section in the instance configuration. I have tried searching for “Environment” in the search bar, but nothing shows up. Is there a specific permission or an “Advanced Mode” I need to toggle to reveal these settings in Deimos?
Globalization Invariant: I would like to apply the DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=1 fix as you suggested, as soon as I can find the menu for it.
.NET Versioning: Thank you for pointing out the 3.1.3 version requirement. I will make sure to use the correct SDK version. However, since I need to set DOTNET_ROOT persistently, I also need access to those Environment Variables to make it work.
Could you please provide the exact path in the UI to access these variables for my instance?
There isn’t a setting, it requires a template change as I said. I have now done that - update your instance from the main page in AMP by clicking on the down arrow icon on the instance tile.
You should only need item 2. The .NET runtime comes with the server.
Thank you for the template update! The server is now starting correctly and the ICU error is resolved. However, I have encountered a new issue: The C# bridge is not loading my custom DLLs.
Even though the Bootstrapper (v3.1.3) initializes and the console shows ‘Loading resources..’, it silently skips my resource (DBTest) without any error message. Both server_logs.txt and server_exceptions.txt remain at 0 bytes.
I have already ruled out the following:
Build: The DLL is explicitly published for .NET Core 3.1 (AnyCPU) and includes the runtimeconfig.json.
Dependencies: I am using MySqlConnector 2.1.13 to match the 3.1 runtime and avoid modern reflection crashes.
Case Sensitivity: Folders and meta.xml entries match exactly (DBTest).
Permissions: I’ve applied chmod -R 777 to the dotnet directory.
It seems the Bootstrapper sees the resource but fails to reflect/load the assembly. Since the environment was just updated, is there a specific security policy or a missing library in the new template that prevents the bridge from loading external .NET assemblies?
I uploaded the files directly through the AMP Web Interface File Manager, so the file ownership is correctly set to amp:amp by default. I also verified this manually via the console.
Despite correct ownership and permissions, the C# bridge still silently skips the resource. This suggests that the issue is not related to file access, but rather how the .NET runtime within the container interacts with external assemblies or a potential missing dependency in the shared runtime environment.
Later:
Although the template seems to include the installer files/binaries within the server folders, it does not actually install the runtime into the container’s OS. Merely having the files present is insufficient because the RAGE:MP bridge specifically looks for the dotnet executable in the system’s $PATH. The template needs to ensure that the runtime is properly registered/linked within the Docker environment so that the command dotnet is globally available.
Thanks for the update! It’s really nice to see that you’re looking into this and taking care of the template improvements.
I’ve been working quite a bit with the C# and MySQL integration on this setup lately. If you ever need a second pair of eyes for testing new settings or if I can help out with some feedback from a developer’s perspective to make the template even better, just let me know. )
Update your instance again from the main page, manage the instance, then also update the server to install the .NET SDK in the instance.
For the time being I have hardwired it to download .NET SDK 3.1.201 (which is the SDK version matching the runtime version 3.1.3 as per Download .NET Core 3.1 (Linux, macOS, and Windows) | .NET). At some point I will look to changing this so it downloads whatever SDK version is appropriate to the runtime version, assuming that ever changes - tho if the runtime version is still on 3.1.3 after all this time, that seems unlikely to change any time soon…