ROS#, the C# bridge that lets a .NET or Unity application talk to ROS

What the bridge actually covers

ROS# is a set of open source software libraries and tools in C# for communicating with ROS from .NET applications, in particular Unity. The project description lists the capabilities: create .NET applications that communicate with ROS nodes, subscribe to and publish topics, handle actions and services, and interact with ROS messages. That list maps onto the four communication patterns ROS offers, which is the right level of completeness for a bridge, because a ROS client that cannot do services or actions is only half useful. The stated purpose is enabling the development of robotics applications, simulations and automation systems within the .NET ecosystem, and the licence is Apache-2.0 with a Siemens copyright line running from 2017 to 2026, so this is a corporate-maintained project with a long runway rather than a community one.

Installing it, and the two distribution routes

There are two ways in, and which one you use depends on whether you are working inside Unity or in a plain .NET project. For Unity, the package is installed through the Unity Package Manager by clicking the add package from git URL option and pasting a URL that points at the repository with a path parameter selecting the package directory. For .NET projects, you head to the NuGet Gallery and install the required packages individually, and the search link given lists the Siemens.RosSharp packages across frameworks including prerelease versions. The documentation notes that ROS# can be used with the Unity Engine and or with any compatible .NET project, and the wiki pages for installing and configuring it for Unity and for .NET cover the other options and the getting started steps.

In Unity Package Manager, click the "Add package from git URL" option
at the top left corner.
Paste the following URL:
https://github.com/siemens/ros-sharp.git?path=/com.siemens.ros-sharp

Platform support, and where the edges are

The support matrix is stated precisely enough to plan against. The dependencies require .NET 8 or .NET Standard 2.1 and Visual Studio 2022 or higher. The Unity package was developed with Unity 2022.3.17f1 LTS and should also be compatible with older versions, but Unity 6 support has not yet been thoroughly tested, although some community members were able to use ROS# with Unity 6. For Unity versions below 2022.3 there is a separate wiki page. The honest summary is that the supported path is a recent Unity LTS, that Unity 6 works for some people in practice but is not a tested configuration, and that the .NET side of the project is the more solid of the two because it has a plain framework requirement rather than an engine version.

The three directories, and what each one does

The repository structure section is the fastest way to understand the project. The com.siemens.ros-sharp directory holds the custom Unity UPM package for integrating ROS# into Unity projects, and it includes the whole ROS# .NET solution along with Unity specific scripts, external dependencies and samples, laid out as Unity recommends. Inside it, Runtime/ has the core scripts and components for the Unity integration, Editor/ has Unity specific editor scripts mainly for UI extensions, Plugins/ holds external dependencies at specific versions, and Samples~/ holds example samples that have to be imported through the package manager window, which is the conventional way to keep samples out of a published package.

com.siemens.ros-sharp/
Runtime/
Editor/
Plugins/
Samples~/

The libraries, and the code generator that keeps them in step

The Libraries/ directory is the .NET solution with the core libraries and tools, and the structure inside it tells you how much of ROS is really implemented. RosBridgeClient/ is the core library for communicating with ROS via websockets, which is the transport and therefore the architectural centre of the project. MessageGeneration/ holds the tools for generating C# classes from ROS message definitions, including messages, actions and services with both ROS1 and ROS2 support, and that generator is what makes the bridge practical, because hand-writing the C# for every message type in a ROS distribution is not a thing anyone should do. Urdf/ parses URDF files and creates Unity GameObjects, which is the piece that connects robot descriptions to the scene. PostBuildEvents/ holds OS specific post build scripts, which exist because the Unity package needs a build step to place its generated and native pieces correctly.

Libraries/
RosBridgeClient/
MessageGeneration/
Urdf/
PostBuildEvents/

Packages for tutorials, and where the project is

There is a ROS Packages directory holding ROS packages that are used by ROS# for tutorial, testing and demonstration purposes, which is a useful distinction because it separates the C# library from the sample ROS graphs that exercise it. The project also maintains a wiki with pages for the showcases, the external dependencies, the project team and acknowledgements, and a contact address for the project team. A CODE_OF_CONDUCT.md, a CONTRIBUTING.md and a SECURITY.md sit at the root, which is the same governance set you would expect from a project with corporate backing. The release history shows steady work: version 2.3.1 on 2026-10-09, 2.3.0 on 2026-09-09 and 2.2.2 on 2026-04-22, so the numbering is not shy about minor bumps and the cadence is roughly monthly. The primary language is C#, the default branch is master, and the last push was on 2026-10-09.

ROS Packages/

Where it fits, and what to check first

The boundary of ROS# is clear from the structure. It is a client side bridge, not a ROS implementation, so there is no node running a ROS master, no serialization stack of its own beyond what the message generator produces, and no replacement for the core. What it gives you is the ability to sit inside a Unity simulation or a .NET service and treat ROS as a set of topics, services and actions rather than as something you have to shell out to or reimplement. The practical checks before you adopt it are the version ones, and they matter more here than in most projects. The Unity floor is a specific LTS build, and Unity 6 is unofficially working for some people, which is a different thing from supported. The .NET floor is a specific framework and a specific toolchain. And the transport is the bridge, so if your ROS deployment is not reachable over WebSockets, none of the rest applies. The project also has community application examples collected in an issue thread, which is where to look for what people have actually built with it rather than what the showcase page shows.

Editorial conclusion

Adopt ROS# if your robotics work happens in Unity or in a .NET application and you need to talk to ROS nodes without leaving that ecosystem, and skip it if you are writing ROS nodes in C++ or Python, where the native client libraries already exist. Verify three things before you commit: that your Unity version is supported, since the package was developed against 2022.3.17f1 LTS and Unity 6 support has not yet been thoroughly tested; that your tooling meets the floor of .NET 8 or .NET Standard 2.1 with Visual Studio 2022 or higher; and that the transport you need is the WebSocket bridge, since that is how the client library communicates with ROS.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. siemens/ros-sharp on GitHub