Auto Dark Mode is a Windows desktop utility that automatically switches between dark and light system themes. In production it operates as a multi-process system: a WinUI 3 settings app (AutoDarkModeApp), a background service with system tray icon (AutoDarkModeSvc running under Windows Forms Application.Run), a lightweight CLI shell for IPC commands (AutoDarkModeShell), and self-update tooling split between a legacy C# updater and two Rust components (adm-updater-rs, adm-downloader-rs). The service evaluates multiple triggers — custom time schedules, sunrise/sunset from geolocation or manual coordinates, Windows Night Light state, ambient light sensor lux readings, battery/energy saver state, GPU load, process blocklists, and system idle — then applies theme changes across Windows components: system/app theme, per-monitor wallpapers, accent color, taskbar color, cursors, touch keyboard, color filters, and user-defined scripts. UI and service communicate over named-pipe IPC with a command/response protocol; configuration persists in YAML files watched via FileSystemWatcher and WMI events. This is purely an application repository; bundled GeoJSON assets and geolocation features serve the scheduling feature, not data research. Architecturally the codebase shows genuine craftsmanship: a governors pattern (TimeSwitchGovernor, NightLightGovernor, AmbientLightGovernor) separates switch-decision logic from switch-execution, switch components (ISwitchComponent/BaseComponent) isolate individual theme pieces, a postpone manager coordinates blocking conditions (GPU, idle, processes, notifications) with expiry callbacks, and a config-update event system decouples YAML changes from feature reactions. The UI follows MVVM with CommunityToolkit, dependency injection, and 25+ localized locales. Maintenance is active with recent commits and an issue-triage workflow, but technical drift is medium: commented-out ZeroMQ code and legacy updater logic remain, updater behavior is triplicated across C# and Rust, localization coverage has drifted (many locales contain untranslated English strings), and core features depend on undocumented Windows COM interfaces (IThemeManager2) and build-version checks that may break with future Windows updates.
TopNotify is a Windows application that allows users to customize how notifications appear and behave on their desktop. The system consists of a background daemon service that intercepts Windows notifications and modifies their presentation based on user preferences, combined with a system tray-accessible GUI built with React/Vite for configuration. The architecture cleanly separates concerns: the daemon handles notification interception and modification using Windows APIs, while the GUI provides user configuration. Communication between components occurs via mailslots for IPC and a shared JSON settings file. The application employs an interceptor pattern where different aspects of notification handling (positioning, sound, text-to-speech) are implemented as pluggable components. Key technical highlights include native C++ code for enumerating Windows notification windows, sophisticated DPI-aware multi-monitor positioning logic, and a clean plugin architecture for notification interceptors. The application is packaged as an MSIX installer with support for both x64 and ARM64 architectures.
Bouncy Castle for .NET is a comprehensive, production-grade cryptographic library providing implementations of a vast range of symmetric and asymmetric ciphers, hash functions, message authentication codes, digital signatures, key agreement protocols, key encapsulation mechanisms (including post-quantum schemes like ML-KEM, ML-DSA, SLH-DSA), secure random number generation (NIST SP 800-90A DRBG), and ASN.1 encoding/decoding (DER, BER, DL). It supports high-level protocol implementations for TLS/DTLS (client and server, including PSK, SRP, and post-quantum key exchange), OpenPGP (RFC 4880/9580), CMS (Cryptographic Message Syntax), CMP, CRMF, OCSP, TSP, and X.509 certificate generation and validation. The library is designed as a class library with a monolithic architecture organized into namespaces (Org.BouncyCastle.Crypto, .Asn1, .Tls, .Bcpg, .Cms, etc.), exposing both low-level primitives and high-level builders. It targets multiple .NET runtimes with conditional compilation for hardware intrinsics (AES-NI, PCLMULQDQ, SSE/AVX) and Span<T> support. The codebase is actively maintained, with ongoing migration from older algorithm names (e.g., Dilithium → ML-DSA) and extensive use of factory patterns and interface-based abstractions, making it a solid foundation for secure application development.
OpenBudgeteer is a personal budgeting application built with .NET 9.0 featuring a Blazor WebAssembly frontend and ASP.NET Core Web API backend. It implements the bucket budgeting methodology, allowing users to manage financial accounts, transactions, budget categories (buckets), automated transaction rules, recurring transactions, and financial reporting. The application supports multiple database providers (MySQL, PostgreSQL) and uses Redis for session storage and application settings. The architecture follows a layered approach with distinct data, service, presentation, and API layers. The data layer uses Entity Framework Core with a repository pattern for data access. The service layer provides business logic through generic and EF Core-specific services. The presentation layer employs the MVVM pattern with Blazor components and ViewModels handling UI state and logic. The API layer exposes RESTful endpoints for the frontend to interact with the backend. Key reusable components include a generic repository pattern, a generic service pattern, a ViewModel base class for Blazor, a fluent CSV bank transaction mapper, and a MudBlazor theme persistence service. These components demonstrate craftsmanship in abstraction and separation of concerns, making them suitable for extraction and reuse in other projects. The application is actively maintained with recent updates to .NET 9.0, MudBlazor, and ApexCharts, indicating low technical drift.
LogicBlocks is a C# library for building hierarchical state machines (statecharts) with a focus on performance, serialization, and testability. It provides a `LogicBlock` base class that manages state transitions via input handlers (`IGet<TInput>`), supports pushdown automaton history, async task integration, and observable bindings. The library includes an `AutoBlock` extension for automatic state preallocation and serialization using Chickensoft's introspection and serialization frameworks, and a Roslyn source generator (`DiagramGenerator`) that produces PlantUML state diagrams from annotated state classes. The codebase is well-structured with extensive unit tests, clean separation of concerns, and a fluent API for bindings. It is designed for AOT environments and game development (Godot). The repository also contains a tutorial and a vending machine example.
Jellyfin is a free software media system that manages, organizes, and streams personal media libraries (movies, TV shows, music, photos, books, live TV). The backend server is written in C# using ASP.NET Core and provides a REST API, WebSocket support, and a plugin system. It handles media metadata aggregation from multiple external providers (TMDB, MusicBrainz, AudioDB, etc.), transcoding via FFmpeg, user authentication and authorization, and real-time session synchronization (SyncPlay). The architecture is modular with separate packages for API controllers, database persistence (EF Core with SQLite), media file naming/parsing, metadata providers, and background scheduled tasks. Key entry points include the main server startup (Jellyfin.Server), API controllers (Jellyfin.Api), and the plugin system (MediaBrowser.Providers.Plugins). External dependencies include FFmpeg for transcoding, SQLite for the database, and various third-party metadata APIs. The codebase demonstrates strong engineering practices with extensive unit and integration tests, a custom event-driven architecture, and a well-defined authorization handler pattern for fine-grained access control. While there are some legacy namespaces and a large number of database migrations indicating schema evolution, the overall structure is clean and maintainable.
DevToys is a cross-platform desktop application that bundles over 30 developer utilities (JSON formatter, Base64 encoder/decoder, hash generator, regex tester, etc.) into a single interface. The application uses an embedded Blazor WebView for its UI, enabling a modern web-like component model with rich editors (Monaco Editor), responsive layouts, and platform-specific theming. It follows an MVVM architecture with MEF (Managed Extensibility Framework) for dependency injection and plugin discovery, allowing third-party extensions to add new tools. The project also includes a CLI variant and an SDK (DevToys.Api) for extension development. Architecturally, the codebase is organized into platform-specific host projects (Windows WPF, macOS AppKit, Linux GTK) that all share a common Blazor UI layer (DevToys.Blazor) and business logic (DevToys.Business, DevToys.Core). Key entry points are the native window classes (e.g., MainWindow.xaml on Windows) which initialize the Blazor WebView and MEF composition. Data flows begin with clipboard or file input, which passes through smart detection services to suggest relevant tools, then renders the tool's UI via a fluent builder API. The settings system uses typed definitions and platform-agnostic storage. External dependencies include .NET 8, Blazor, SixLabors.ImageSharp, Monaco Editor (downloaded and vendored), and several community libraries (FuzzySharp, OneOf, System.CommandLine). The codebase demonstrates strong engineering practices: extensive localization (40+ languages), accessibility features, theme support (dark/light/compact), and a comprehensive Blazor component library. While the MEF-based plugin system is functional, it relies on the legacy System.ComponentModel.Composition package, and the platform-specific implementations (e.g., file storage, clipboard) are duplicated across Windows, macOS, and Linux, posing a moderate maintenance burden.
The Windows App SDK (formerly Project Reunion) is a Microsoft platform SDK for building modern Windows desktop applications. It provides a unified set of WinRT APIs and runtime components that bridge Win32 and UWP development, enabling features like app lifecycle management (single-instance, file/protocol activation), dynamic package dependencies (resolving framework packages at runtime), rich notifications (toast, push, badge), resource management via MRT Core (PRI files with qualifier-based selection), deployment APIs (package sets, validation), environment variable management, OAuth 2.0 authentication, and interop wrappers for storage pickers and camera capture. The architecture is modular: each feature area is implemented as a separate C++/WinRT component (DLL) that can be consumed individually via NuGet packages. The SDK supports both packaged (MSIX) and unpackaged (self-contained) apps, with a bootstrap DLL that initializes the runtime and hooks into the Windows package graph via Detours. Key entry points include MddBootstrapInitialize2 for runtime initialization, the WindowsAppRuntime DLL for COM class factories, and individual component APIs like AppNotificationManager, PushNotificationManager, and PackageDependency. External dependencies include the Windows SDK, C++/WinRT projections, the Windows Implementation Libraries (WIL), and Microsoft Detours for API interception. Data flows involve inter-process communication through shared memory (for activation redirection), named pipes (for OAuth callbacks), and COM out-of-process servers (for push notification long-running tasks). The codebase is heavily instrumented with TraceLogging telemetry and uses feature flags (TerminalVelocity) to gate experimental APIs.
ppy/osu-framework is a high-performance, cross-platform game framework written in C#, primarily designed to power the rhythm game osu! but offering general-purpose 2D game development capabilities. The codebase provides a comprehensive suite of subsystems including a hardware-accelerated rendering pipeline (OpenGL/Veldrid), a sophisticated input handling system (mouse, keyboard, touch, tablet, joystick, MIDI), an audio engine built on BASS and FFmpeg, a rich animation and layout system, and a full-featured UI toolkit with containers, text rendering, and interactive controls. It employs Roslyn source generators to eliminate runtime reflection for dependency injection and input dispatch. The architecture is modular, heavily test-driven (thousands of unit and visual tests), and supports Windows, macOS, Linux, iOS, and Android through platform-specific host implementations. Despite its strong engineering, the codebase shows signs of ongoing migration to SDL3, dual rendering backends, and reliance on unmanaged native libraries that require periodic updates.
The JT808Gateway is a .NET 10.0-based implementation of a gateway for the JT/T 808 protocol, commonly used in Chinese vehicle telematics systems. It handles TCP/UDP connections from vehicle terminals, processes JT808 messages (such as location reports, status updates, and commands), and provides mechanisms for sending downlink messages to devices. The gateway integrates with Apache Kafka for message queuing and decoupling, and offers a WebApi for management operations and real-time monitoring via SignalR. The architecture follows a modular design with clear separation of concerns: the core gateway handles transport and message routing, abstractions define extensibility points for custom integrations, and hosted services manage background tasks like logging and session notices. The system uses System.IO.Pipelines for high-performance I/O and employs the builder pattern for configuration. Session management is robustly implemented to track device connections by terminal ID, ensuring reliable state tracking for online/offline events. Key reusable components include the abstraction layer (enabling pluggable transports and message handlers) and the session management module (providing thread-safe session lifecycle management). The gateway also features comprehensive testing and benchmarking suites to validate performance and correctness under load. While the codebase shows signs of active maintenance with recent updates, it contains some obsolete markers indicating ongoing evolution, and the dual-mode architecture (simple vs queue-based) may introduce complexity that requires careful consideration for deployment.
Files is a modern, open-source Windows file manager built with WinUI 3 and .NET 10, featuring multitabbing, dual-pane navigation, file tags, cloud drive integration, FTP support, Git version control, and a widget-based home page. The architecture is a modular monolith with separate projects for the main app (Files.App), a server component (Files.App.Server), storage abstractions (Files.App.Storage, Files.Core.Storage), a source generator for CsWinRT interop (Files.Core.SourceGenerator), and custom UI controls (Files.App.Controls). The codebase makes heavy use of source-generated P/Invoke via CsWin32, Roslyn source generators for VTable functions and command managers, and the CommunityToolkit.Mvvm pattern with ObservableObject and dependency property source generation. The app supports MSIX packaging, sideload and Store distribution channels, and includes C++/COM components for custom open/save dialogs and a launcher. The last commit was on 2026-06-30, and the project has 44k stars with active CI/CD workflows.
BlazorBlueprint is a comprehensive Blazor UI component library inspired by shadcn/ui, providing over 112 styled components and 28 headless primitives. It targets .NET 8 across Server, WebAssembly, and Auto render modes, with full accessibility (ARIA, keyboard navigation), theming via CSS custom properties (compatible with shadcn CSS variables), and zero Tailwind/Node setup. The library is split into two layers: Primitives (headless, behavioral components with focus management, positioning, and portal services) and Components (styled, ready-to-use widgets like DataGrid, charts, forms, dialogs, and navigation). It ships with four icon libraries (5,200+ icons) and 11 chart types via Apache ECharts. The architecture emphasizes composability through cascading contexts, a consistent form-field pattern, and a utility-first approach with the ClassNames.cn helper for Tailwind class merging. The codebase demonstrates strong engineering practices: extensive use of generics, expression trees for filtering, JS interop with guarded disposal, and a localization system with 200+ string keys. However, the large API surface, heavy JS interop, and limited test coverage (only a few unit tests for DataGrid and hierarchy utilities) present maintenance risks.
This repository is a comprehensive .NET SDK for the Alpaca Markets API, providing both REST and WebSocket clients for algorithmic trading, market data retrieval (stocks, crypto, options), and account management. The architecture is a layered client library with core (`Alpaca.Markets`) and extensions (`Alpaca.Markets.Extensions`) NuGet packages, targeting multiple .NET frameworks (netstandard2.0/2.1, net462, net8.0, net10.0). Entry points include configuration classes that instantiate typed clients (e.g., `IAlpacaTradingClient`, `IAlpacaDataClient`, `IAlpacaCryptoDataClient`, `IAlpacaOptionsDataClient`) via environment-specific base URLs (live, paper). The library supports advanced order types (bracket, OCO, trailing stop), real-time streaming with automatic reconnection, and efficient pagination using `IAsyncEnumerable`. The codebase exhibits high craftsmanship with clean separation of interfaces, messages, and parameters; fluent builder patterns for orders; and robust testing infrastructure using mocks. The extensions package adds DI integration (`AddAlpaca*Client`), Polly-based retry, and reusable subscription management. While the SDK is actively maintained and well-tested, it relies on Newtonsoft.Json (rather than System.Text.Json) and maintains compatibility with older frameworks, adding complexity. A minor risk is dependency on internal Alpaca API endpoints that could change, but the library's design isolates these concerns.
PowerThreadPool is a high-performance .NET thread pool library designed for managing both synchronous and asynchronous workloads with granular control. It implements a low-contention thread pool using work-stealing priority queues, lock-free synchronization primitives, and sophisticated state management for workers and work items. The library provides features like work dependency tracking, group-based operations, pause/resume/cancel controls, timeout/retry policies, and event-driven monitoring. Architecture centers around the PowerPool class managing Worker instances that execute work from concurrent collections, with async support via custom synchronization contexts. Entry points include QueueWorkItem overloads for submitting work and control methods like Start/Stop/Pause/Resume. The library targets .NET Framework 4.0+ through .NET 5+ and netstandard, demonstrating careful backward compatibility through conditional compilation.
This repository implements the Wave Function Collapse (WFC) algorithm, a constraint-based procedural content generation technique. The system takes an input bitmap (or a tileset with adjacency rules) and generates a larger output bitmap that is locally similar to the input, meaning every N×N pattern in the output appears somewhere in the input. It supports two primary models: the OverlappingModel, which extracts patterns from a sample image, and the SimpleTiledModel, which uses predefined tiles and adjacency constraints defined in XML. The algorithm operates by maintaining a 'wave' of possible states for each output cell, iteratively collapsing the cell with the lowest Shannon entropy and propagating constraints until a fully observed state is reached or a contradiction occurs. The architecture is a straightforward console application written in C# targeting .NET 10. The entry point is Program.cs, which reads a configuration file (samples.xml) specifying model parameters and input samples. The core algorithm is encapsulated in the abstract Model class, with concrete implementations in OverlappingModel.cs and SimpleTiledModel.cs. Image loading and saving are handled by the BitmapHelper class using the SixLabors.ImageSharp library. The system outputs PNG images to an 'output' directory. External dependencies are minimal, relying only on ImageSharp for bitmap I/O. The codebase is well-structured and demonstrates clean separation of concerns. The algorithm implementation is faithful to the original paper and includes optimizations such as the AC-4 constraint propagation algorithm and multiple heuristic strategies (entropy, MRV, scanline). The tile symmetry system in SimpleTiledModel reduces the number of explicit adjacency rules needed. While the repository is primarily a reference implementation, its components—particularly the helper utilities and the core propagation logic—are reusable in other procedural generation projects.
OGRE (Object-Oriented Graphics Rendering Engine) is a mature, production-grade 3D rendering engine written in C++ with extensive cross-platform support. The codebase implements a modular plugin architecture with render system backends for Direct3D 9/11, OpenGL (legacy, 3+, ES2), Metal, Vulkan, and a software Tiny renderer. Core modules include scene management, material/shaders, resource handling, animation, particle systems, and compositor framework. Optional components provide real-time shader generation (RTShaderSystem), automatic mesh LOD generation, terrain rendering, volume rendering, world paging, and a 2D overlay system. The repository also includes Python bindings, sample applications, fuzz testing, and content pipeline tools (exporters for Maya, Milkshape, Wings3D). The architecture follows design patterns such as Singleton managers, Factory-based extensibility, and a work queue for background loading. Despite its age and size, the engine remains actively maintained with recent commits, CI/CD pipelines, and support for modern graphics APIs. Notable technical debt includes legacy render backends, deprecated APIs, and some tightly coupled subsystems.
MessagePipe is a high-performance C# library for in-process and distributed messaging, implementing pub/sub, mediator/CQRS, and request/response patterns with a flexible filter pipeline. It supports both synchronous and asynchronous operations, keyed and keyless subscriptions, and buffered/observable adapters. The library is DI-container agnostic, with first-class integrations for Microsoft.Extensions.DependencyInjection, Unity (Zenject, VContainer), and a built-in lightweight container. Distributed transports include TCP, UDP, Named Pipes, Unix Domain Sockets, Redis, and NATS, with MessagePack binary serialization. A Roslyn analyzer (MPA001) detects forgotten subscription disposal. The codebase is well-structured and performance-optimized (lock-free data structures, pooling, custom awaiters), but suffers from significant code duplication between .NET and Unity variants and embeds large third-party libraries (Zenject, MessagePack) directly in the Unity project, increasing maintenance burden.
GirCore is a comprehensive C# binding generator and runtime library for GObject-based native libraries (GTK, GStreamer, WebKit, Cairo, etc.). It reads GObject Introspection (GIR) XML files and produces strongly-typed C# bindings with P/Invoke declarations, SafeHandle memory management, and high-level managed APIs. The architecture consists of a generation pipeline (GirLoader parses GIR, GirModel defines an interface-based intermediate representation, Generator applies fixers and renders C# code via a modular converter system) and a set of runtime libraries (GLib, GObject, Gtk, etc.) that provide safe wrappers, signal handling, subclassing support, and platform abstraction. Key entry points include the GirTool CLI for regeneration, Module.Initialize() for library initialization, and Roslyn source generators/analyzers for GObject subclassing and GTK composite templates. The project is pre-1.0 but actively used by several desktop applications and the .NET MAUI Linux backend.
Equinox is an F# library for event-sourced systems, providing a consistent abstraction over multiple stream-based storage backends including CosmosDB, DynamoDB, EventStoreDB, MessageDB, SqlStreamStore, and an in-memory store. In production, it enables applications to define domain logic as pure decision functions that produce events, while the library manages optimistic concurrency, caching, snapshots, and retries. The core is the `Decider` pattern: an aggregate loaded from a stream, a decide function that returns events, and a fold that applies events to produce new state. Access strategies (e.g., `LatestKnownEvent`, `RollingSnapshots`, `Custom`) control how state is reconstructed from stored events, trading read cost for write cost. The architecture is modular: the `Equinox` package defines the core interfaces (`ICategory`, `IStream`, `Decider`), while separate NuGet packages implement storage adapters. The library is used as a dependency in larger applications; sample projects (`Store/Domain`, `TodoBackend`, `Tutorial`) demonstrate its use. Key entry points include the `Decider` class for command/query execution, `Category` for resolving streams, and store-specific connectors (e.g., `CosmosStoreConnector`, `DynamoStoreConnector`). A CLI tool (`Equinox.Tool`) provides provisioning, benchmarking, and data inspection commands across all stores. External dependencies are minimal per package: `Equinox` depends only on `FsCodec` for serialization; store adapters require their respective SDKs (Azure.Cosmos, AWSSDK.DynamoDBv2, EventStore.Client, Npgsql, etc.). The library includes comprehensive caching (`Equinox.Cache` wrapping `System.Runtime.Caching.MemoryCache`), metrics via Prometheus, and a load testing harness. Despite some deprecated adapters (legacy EventStore TCP, SqlStreamStore) and high complexity from multiple backends, the core patterns are clean, well-tested, and production-proven at Jet.com.
The GodotSharp.SourceGenerators repository provides a set of Roslyn source generators designed to enhance the Godot Engine C# development experience. These generators inspect C# source code for specific attributes (such as `[SceneTree]`, `[AnimNames]`, `[AudioBus]`, etc.) and generate corresponding strongly-typed accessor code, eliminating the need for magic strings and improving compile-time safety. The project supports both Godot 3 and Godot 4 versions, with a clear migration path outlined in the documentation. The architecture follows a modular pattern where each feature (e.g., scene tree access, animation names) is implemented as a separate extension. Each extension consists of an attribute, a data model, a scraper to extract information from the project and source files, a source generator that uses Scriban templates to produce C# code, and the template itself. Shared utilities handle common tasks such as path resolution, string manipulation, and unique ID generation, promoting code reuse and consistency across generators. The repository includes extensive test suites for both Godot 3 and 4, validating the generated code against various scenarios including inheritance, same-name handling, nullable reference types, and edge cases. This ensures the generators remain robust despite Godot's evolving API. The project is actively maintained, with recent commits and a structured approach to handling breaking changes between versions.