Problem Details
Rapid SCADA installs on a Raspberry Pi 3B+ following the generic Linux procedure, but the web application and service layers throw errors during or immediately after installation. The failure pattern reported is that the ASP.NET Core Runtime 8.0.x installation was never actually functional, even though the operator believed it had been installed. The Rapid SCADA server and web components are .NET applications; if the ASP.NET Core shared framework is absent or the wrong architecture, startup fails with framework-resolution errors rather than an obvious "missing package" message.
dotnet --list-runtimes proves otherwise.Root Cause
Two distinct causes produce the same visible symptom:
-
No usable ASP.NET Core shared framework. Rapid SCADA's web module requires the
Microsoft.AspNetCore.Appshared framework. Installing onlyMicrosoft.NETCore.App(the base .NET runtime) is not sufficient — the web layer will not start. -
Package feed / architecture mismatch on Raspberry Pi OS. Raspberry Pi OS is Debian-derived. Adding a Microsoft feed configured for a different distribution or release (for example an Ubuntu
22.04prod.list) may resolve packages inconsistently against the running OS and CPU architecture. On a 32-bit userland, ARM64 packages will not resolve at all.
A third, secondary issue: installing dotnet-sdk-8.0 pulls in a full SDK. That works — the SDK carries the runtimes as dependencies — but it consumes significantly more storage on an SD card and is unnecessary for running a deployed SCADA application. The SDK is a compiler toolchain, not a runtime requirement.
Solution A: Scripted Runtime Install (Recommended)
The Microsoft dotnet-install.sh script installs an explicit runtime version to a chosen directory, independent of the distribution package feed. This avoids all feed/architecture mismatch problems and installs only the ASP.NET Core runtime.
curl -sSL https://dot.net/v1/dotnet-install.sh | sudo bash /dev/stdin \
--version 8.0.11 \
--runtime aspnetcore \
--install-dir /usr/share/dotnet/| Argument | Effect |
|---|---|
--runtime aspnetcore |
Installs the ASP.NET Core shared framework, which also brings the base .NET runtime. No SDK. |
--version 8.0.11 |
Pins an exact patch. Removes ambiguity about which 8.0.x landed on the machine. |
--install-dir /usr/share/dotnet/ |
System-wide location. Matches the path used by feed-installed packages, so services resolve it consistently. |
The script does not create a dotnet entry in PATH by itself. Add a symlink so services and shells resolve the binary:
sudo ln -sf /usr/share/dotnet/dotnet /usr/bin/dotnet
dotnet --list-runtimesSolution B: Microsoft Package Feed Install
This path uses APT and works on a 64-bit Raspberry Pi OS install. The sequence below is the one confirmed to complete successfully on Raspberry Pi 64-bit:
sudo apt-get install -y gpg
wget -O - https://packages.microsoft.com/keys/microsoft.asc \
| gpg --dearmor -o microsoft.asc.gpg
sudo mv microsoft.asc.gpg /etc/apt/trusted.gpg.d/
wget https://packages.microsoft.com/config/ubuntu/22.04/prod.list
sudo mv prod.list /etc/apt/sources.list.d/microsoft-prod.list
sudo chown root:root /etc/apt/trusted.gpg.d/microsoft.asc.gpg
sudo chown root:root /etc/apt/sources.list.d/microsoft-prod.list
sudo apt-get update && sudo apt-get install -y dotnet-sdk-8.0Two corrections worth applying to this sequence before you run it:
-
Substitute the runtime for the SDK. Replace
dotnet-sdk-8.0withaspnetcore-runtime-8.0unless you intend to compile modules on the Pi. This cuts the install footprint substantially on an SD card. -
The
prod.listis an Ubuntu 22.04 feed. It is being applied to a Debian-derived Raspberry Pi OS. It resolves in practice for many users, but it is a cross-distribution configuration. If you hit dependency conflicts against system libraries, fall back to Solution A, which sidesteps the feed entirely.
chown root:root lines are not optional. Files written by wget under a non-root user retain that ownership; APT rejects sources and keyring files not owned by root, and the failure message points at the repository rather than the file permission.Verification
Run these checks in order before starting any Rapid SCADA service. Each one isolates a different failure mode.
| # | Command | Expected result |
|---|---|---|
| 1 | uname -m |
aarch64 for 64-bit. If armv7l, the ARM64 packages will not install — reimage with 64-bit Raspberry Pi OS or use an ARM32 runtime. |
| 2 | dotnet --info |
Binary resolves; reports RID and install path. |
| 3 | dotnet --list-runtimes |
Must list a Microsoft.AspNetCore.App 8.0.x line. A Microsoft.NETCore.App line alone is a failed install for Rapid SCADA purposes. |
| 4 | which dotnet |
Returns a path. Empty output after Solution A means the symlink step was skipped. |
Step 3 is the decisive test. The reported root cause — a runtime that "was not working at all" — is exactly what this command exposes. If Microsoft.AspNetCore.App is absent, no amount of Rapid SCADA reconfiguration will help.
Service Startup and Log Triage
After the runtime verifies clean, start the Rapid SCADA services and read their status. Do not judge success from the absence of console output:
sudo systemctl status scadaserver
sudo systemctl status scadacomm
sudo systemctl status scadaweb
# Full journal for a failing unit
sudo journalctl -u scadaweb -n 200 --no-pagerInterpret what you find using this triage table:
| Log content | Likely cause | Action |
|---|---|---|
Framework Microsoft.AspNetCore.App not found |
Runtime missing or installed to a directory the service cannot resolve | Re-run Solution A with --install-dir /usr/share/dotnet/ and recreate the symlink |
| Permission denied on a Rapid SCADA directory | Install files owned by the wrong user after extraction | Correct ownership on the Rapid SCADA install tree; verify the service account matches |
| Address already in use / port bind failure | Another web service holds the port | Identify the holder with sudo ss -ltnp and either stop it or change the Rapid SCADA web port |
| Unit not found | Service files were never registered | Re-run the Rapid SCADA install step that registers systemd units, then sudo systemctl daemon-reload
|
dotnet --list-runtimes, and uname -m. "Installation errors" without the verbatim message cannot be diagnosed — the same visible failure has at least four distinct causes listed above.Platform Notes for Raspberry Pi 3B+
| Consideration | Guidance |
|---|---|
| OS architecture | Use 64-bit Raspberry Pi OS. The confirmed-working package sequence targets ARM64. |
| Storage medium | SD cards degrade under sustained logging writes. Reduce archive write frequency or relocate archives to external storage for long-running deployments. |
| Install footprint | Runtime-only install (Solution A or aspnetcore-runtime-8.0) is materially smaller than the full SDK. |
| Reproducibility | Pin the .NET patch version. Image the SD card once the system verifies clean so field replacements are identical. |
Frequently Asked Questions
Do I need the .NET SDK to run Rapid SCADA on a Raspberry Pi?
No. Rapid SCADA needs the ASP.NET Core 8.0 runtime, not the SDK. Install aspnetcore-runtime-8.0 via APT, or use dotnet-install.sh with --runtime aspnetcore. The SDK works but wastes SD card space.
How do I confirm the ASP.NET Core runtime actually installed?
Run dotnet --list-runtimes. You must see a Microsoft.AspNetCore.App 8.0.x entry. Seeing only Microsoft.NETCore.App means the base runtime installed but the web framework did not, and Rapid SCADA's web module will fail.
Why does the install sequence use an Ubuntu 22.04 package feed on Raspberry Pi OS?
It is a cross-distribution configuration that resolves in practice on 64-bit Raspberry Pi OS, which is Debian-derived. If you hit dependency conflicts, switch to the dotnet-install.sh script method, which bypasses APT feeds entirely.
Why does APT reject my Microsoft repository after adding it?
Files moved with wget and mv keep non-root ownership. Run sudo chown root:root on both /etc/apt/trusted.gpg.d/microsoft.asc.gpg and /etc/apt/sources.list.d/microsoft-prod.list, then sudo apt-get update again.
Does Rapid SCADA run on 32-bit Raspberry Pi OS?
The confirmed-working install path here targets ARM64. Check with uname -m — if it returns armv7l you are on 32-bit and the ARM64 packages will not resolve. Reimage with 64-bit Raspberry Pi OS for the documented procedure.
