The Problem
Sharing a screen with colleagues or friends typically means installing a third-party cloud service (Zoom, TeamViewer, etc.), which introduces latency, privacy concerns, and dependency on external infrastructure. OpenScreen addresses this by providing a self-hosted, local-network screen sharing tool that streams directly from your machine to any browser on the same network.
What This Does
OpenScreen is a Windows desktop application built with C# 7.3 on .NET Framework 4.7.2. The core streaming logic lives in OpenScreen.Core/, which handles screen capture (Screenshot/Screenshot.cs), MJPEG encoding (Mjpeg/MjpegWriter.cs, Mjpeg/MjpegStream.cs), and the HTTP streaming server (Server/StreamingServer.cs). The WPF front-end in OpenScreen/ provides the UI for selecting which screen or application window to share, toggling cursor visibility, and adjusting FPS and quality settings.
The application streams MJPEG over HTTP, which means any device with a browser—phone, tablet, or computer—can view the stream without installing client software. The ServerConfig.cs file manages server settings like port and quality parameters.
How To Use It
Setup: The project is a Visual Studio 2019 solution (OpenScreen.sln) targeting .NET Framework 4.7.2. Build it in Visual Studio or via msbuild. An MSI installer (OpenScreen.Installer/OpenScreen.Installer.vdproj) is available from the releases page.
Configuration: No environment variables or external config files are required. All settings (FPS, quality, cursor visibility) are configured through the WPF UI at runtime.
Running it: Build the solution in Visual Studio 2019, then run OpenScreen.exe Or download and install OpenScreen-Installer.msi from the releases page
The README documents cloning the repo and building in Visual Studio. The installer path is the more practical option for end users.
Real-World Use
A developer working in an office needs to show a colleague on the same LAN a rendering bug in their application. They launch OpenScreen, select the specific application window, enable cursor display, set FPS to 15 for smooth motion, and share the local IP and port. The colleague opens the URL in their browser and sees a live view without any client installation or third-party service.
Code Health & Issues
Med – No test coverage: The repo has zero test files. The MJPEG encoder and streaming server handle binary data and network I/O—exactly the kind of code that benefits from automated tests. Any refactoring carries regression risk. Med – No CI/CD pipeline: No .github/ workflows or CI config exists. There is no automated build or test gate, so regressions can ship unnoticed. Low – Windows-only: The code is tightly coupled to Windows APIs (WinFeatures/ApplicationWindow.cs, WinFeatures/MouseCursor.cs, RunningApplications.cs). This is fine for the stated use case but limits portability. Low – No input validation: The streaming server accepts HTTP requests, but there is no evidence of request validation, rate limiting, or authentication. On an untrusted network, anyone could connect to the stream. Low – No security controls: The stream is unencrypted HTTP with no authentication mechanism. This is acceptable for trusted LANs but a risk on shared or public networks.
The Bottom Line
OpenScreen is a functional, focused solution for LAN-based screen sharing with a clean separation between the streaming core and the WPF UI. It is well-suited for small teams or individuals who want a self-hosted alternative to cloud screen sharing and are comfortable with Windows-only, .NET Framework tooling. The lack of tests, CI, and security controls means it is not production-grade for untrusted environments, but it is a solid starting point for internal use or as a base for further development.