Architecting a Secure, Hot-Reloadable Plugin Framework in C\

Full report

On this page

The Paradigm of Dynamic Modularity and Centralized Discovery

The architectural landscape of enterprise software has undergone a profound transformation, moving away from monolithic deployments toward highly dynamic, extensible ecosystems. Modern systems increasingly require the ability to discover, download, and execute discrete feature sets at runtime without triggering application-wide redeployments or service interruptions. In the context of a highly extensible C\# application—specifically one designed to interface with a centralized plugin repository and update service such as "LocalEndpoints.com"—the architecture must reconcile several competing operational mandates. These mandates include strict memory isolation, seamless host-plugin type sharing, decentralized cryptographic trust, and the elusive goal of zero-downtime hot-swapping. The name "LocalEndpoints" is particularly evocative in this domain, as it mirrors the fundamental networking and boundary primitives required to bind isolated execution contexts into a cohesive whole.1 Historically, the.NET Framework relied on AppDomain boundaries to establish in-process isolation. However, the transition to modern.NET (Core 3.0 through.NET 8 and beyond) deprecated the AppDomain in favor of a vastly more performant, lightweight, and nuanced mechanism known as the AssemblyLoadContext (ALC).3 While the ALC provides exceptional logical scoping for managed assemblies, it introduces profound complexities regarding cooperative memory unloading, garbage collection finalization, and native dependency resolution.4 Concurrently, applications demanding absolute fault tolerance—where a catastrophic memory access violation in a third-party plugin must not corrupt the host process—are moving away from in-process loading entirely. Instead, architects are favoring Out-of-Process (OoP) architectures utilizing Inter-Process Communication (IPC) over technologies such as gRPC, Unix Domain Sockets (UDS), and Named Pipes.6 This comprehensive report provides an exhaustive, deeply technical analysis of the mechanisms required to engineer a completely custom, secure, and hot-reloadable C\# plugin application connected to a centralized "LocalEndpoints.com" distribution hub. The analysis traverses the internal mechanics of the CoreCLR type system, the intricacies of cooperative memory unloading and file-lock mitigation, the implementation of secure inter-process communication, and the cryptographic supply-chain verification required to safely ingest arbitrary executable code.

In-Process Isolation and the AssemblyLoadContext Architecture

At the core of modern.NET dependency loading is the AssemblyLoadContext. Every.NET 5+ application implicitly operates within a default context, known as AssemblyLoadContext.Default, which serves as the runtime's primary provider for locating, loading, and caching managed dependencies.3 When a host application creates a modular architecture, it must explicitly instantiate custom, isolated contexts for each plugin. This isolation is not a security boundary; code executed within an ALC runs with the full permissions of the host process.3 Rather, it is a logical boundary designed to resolve dependency version conflicts.

The Mechanics of Logical Isolation and Versioning

The fundamental purpose of the ALC is to prevent dependency hell—a scenario where multiple modules require conflicting versions of the same commonly used library. A single ALC instance is restricted to loading exactly one version of an assembly per simple assembly name.4 If an assembly reference is resolved against a context that already possesses an assembly of that name, the resolution succeeds only if the loaded version is equal to or higher than the requested version.4 By creating a derived implementation of AssemblyLoadContext (for instance, a custom PluginLoadContext), the runtime establishes a unique dictionary mapping each AssemblyName.Name to a specific Assembly instance.4 Because each ALC represents a distinct scope, there is no inherent binary isolation between dependencies. They are isolated simply by not locating each other by name.4 Consequently, within two separate ALCs, an identically named type will manifest as two entirely distinct instances in memory. Invoking Type.GetType() on the same fully qualified class name will yield incompatible type definitions across boundaries, a phenomenon that fundamentally alters how host applications must design their interfaces.4

Dynamic Dependency Resolution Strategies

To successfully instantiate a plugin, the custom ALC must override the virtual Load(AssemblyName) and LoadUnmanagedDll(string) methods.8 Within these overrides, the runtime must dynamically locate the physical binaries on disk. Modern implementations leverage the AssemblyDependencyResolver, a framework type designed specifically to parse the .deps.json file generated during the plugin's compilation.8 When the host application queries the AssemblyDependencyResolver.ResolveAssemblyToPath(assemblyName) method, the resolver traces the exact dependency graph dictated by the plugin's project file.8 If a match is found within the plugin's local directory hierarchy, the custom ALC invokes LoadFromAssemblyPath to map the binary into the current isolated context.8 If the resolver returns null, indicating the dependency is not locally bundled, the custom ALC can deliberately fall back to the AssemblyLoadContext.Default, allowing the plugin to utilize the host's dependencies if they are present.8 The runtime also raises a Resolving event as a fallback mechanism, providing a final opportunity to locate the assembly programmatically before throwing a FileNotFoundException.3 A secondary architectural insight emerges when considering the compilation of the plugins themselves. For the AssemblyDependencyResolver to correctly catalog all necessary transitives in the .deps.json file, the plugin's .csproj file must be explicitly configured with the \<EnableDynamicLoading\>true\</EnableDynamicLoading\> property.8 This MSBuild directive instructs the compiler to copy all resolved implementation assemblies to the output directory, preparing the project to function as an independent, self-contained module rather than assuming the host environment will provide the required libraries.8 Furthermore, plugins should target a specific runtime identifier (such as.NET 8 or.NET 10\) instead of.NET Standard, ensuring that the deployment manifest maps implementation assemblies rather than abstract reference assemblies.8

Boundary Permeability: Overcoming the Type-Unification Dilemma

While ALC isolation perfectly solves the problem of version collisions among third-party packages, it simultaneously fractures the host application's ability to communicate fluently with the plugin. This operational friction is known as the Type-Unification Problem.7

The Isolation Paradox and Type Identity

Consider an architecture where the host application and multiple plugins (for example, a "Payment Gateway Plugin" and an "Analytics Plugin") all reference a shared data contract library containing an interface named IPlugin.7 If the default dependency resolution behavior is permitted, the host will load its copy of the contract into the Default context, while each plugin will load its local copy into its respective isolated ALC.7 Because the Common Language Runtime (CLR) defines type identity by combining the type name with its containing assembly and its executing load context, the IPlugin interface residing in the payment plugin is mathematically and logically distinct from the IPlugin interface in the host.7 Attempting to cast an instantiated object from the plugin to the host's IPlugin interface will immediately trigger an InvalidCastException, completely severing the ability to pass structured objects, dependency injection containers, or event handlers across the boundary.

Forcing Shared Types across the Context Boundary

To solve the unification dilemma, the runtime must intentionally compromise the isolation boundary for specifically designated "shared types." When the custom ALC evaluates a load request, it must intercept requests for the shared contract assemblies.7 Instead of resolving these assemblies from the plugin's local directory via the AssemblyDependencyResolver, the ALC explicitly delegates the load request to AssemblyLoadContext.Default.LoadFromAssemblyName(assemblyName).7 By doing so, the CLR ignores the local copy of the dependency and forces the plugin to utilize the exact memory instance of the assembly loaded by the host, unifying the types and allowing safe polymorphic casting.7 Within the.NET ecosystem, two prominent architectural frameworks have emerged to abstract this complexity: Nate McMaster's DotNetCorePlugins and Maarten Merken's Prise.

Both approaches highlight the necessity of meticulous boundary management. By establishing a shared contract assembly containing only the interfaces required for initialization and communication, the host application can minimize its dependency footprint while maintaining a rigid integration standard.9

Scoped Dependency Injection and MVC Controller Discovery

Permeability also profoundly affects the application's service layer. Modern.NET applications rely heavily on Dependency Injection (DI) to manage object lifecycles. However, static states and singleton services present a severe memory risk in dynamic plugin environments. Second-order analysis dictates that a plugin should never share a singleton service container with the host unless explicitly designed as an immutable shared resource. Instead, each plugin must be allocated its own scoped DI container (for example, an Autofac LifetimeScope or an isolated IServiceCollection provider) upon initialization.9 This scoped approach ensures that when a plugin is targeted for unloading, its entire service graph is safely discarded without orphaned references leaking back into the host's default context.9 Furthermore, integrating plugins into an ASP.NET Core web environment introduces complications regarding controller discovery. Controllers defined within isolated plugins are not automatically discovered by the primary application's MVC routing engine.9 To bridge this gap, the host must manually register the plugin's controllers into the routing table using the ApplicationPartManager. By iterating through the ApplicationPartFactory.GetApplicationParts(pluginAssembly) and adding them to the manager, the host can dynamically expose RESTful endpoints defined within the dynamically loaded plugin module.9

Memory Management, Hot-Reloading, and Resource Finalization

The operational promise of a central "LocalEndpoints.com" plugin store is the ability to fetch a newly published version of a module and apply it in real-time without restarting the primary host application. This capability requires completely unloading the old plugin, freeing its associated memory resources, and mitigating file-system locks. However, the CLR's implementation of assembly unloading is fundamentally cooperative, introducing significant architectural friction and the constant threat of memory leaks.5

Cooperative Unloading Mechanics

To enable unloading, the custom ALC must be instantiated with the parameter isCollectible: true.9 When an update is retrieved from the store, the host application invokes the AssemblyLoadContext.Unload() method.9 Crucially, this method does not forcefully eject the module from memory in the way that destroying an OS process would. Instead, it merely signals to the runtime Garbage Collector (GC) that the context is eligible for finalization and collection.5 The actual removal of the assembly from memory only occurs when absolutely zero strong references to any object, type, or execution thread originating from that context remain active in the broader application memory space.5 A single stray event subscription, an undisposed background task, a cached reflection property, or a type leak back to the default context will permanently block the finalizer, preventing the unload.9 Therefore, plugin authors must implement rigorous Dispose patterns. Before invoking the unload command, the host must trigger a shutdown sequence that halts all asynchronous tasks, clears all event handler subscriptions, and decisively destroys the plugin's scoped dependency injection container.9

Diagnostic Verification via WeakReferences

To programmatically verify whether an ALC has successfully unloaded—a critical requirement for preventing cumulative memory leaks over successive hot-reloads—architects utilize the WeakReference pattern.15 By wrapping the ALC instance in a WeakReference before nullifying the strong reference to it, the application can force a garbage collection cycle and monitor the reference status. A typical diagnostic implementation involves a constrained loop that invokes GC.Collect() and GC.WaitForPendingFinalizers() while checking the IsAlive property of the weak reference.15 If the weak reference drops to null, the runtime has successfully purged the load context. However, if the reference persists indefinitely, a memory leak is mathematically guaranteed. In such scenarios, developers must resort to complex memory dump analysis using advanced debugging tools like WinDbg.14 By attaching the debugger and executing the \!gcroot command against the memory address of the ALC, the developer can trace the exact chain of strongly rooted objects preventing collection.14 Interestingly, situations often arise where \!gcroot reports zero roots, yet the memory remains allocated; this typically indicates that a thread is still actively executing code within the ALC scope, a condition that can be verified using the \!clrstack command to inspect the call stacks of active OS threads.14

File Locking and the Shadow Copy Workaround

A severe third-order consequence of the.NET runtime's interaction with the host operating system's file I/O layer emerges during the hot-swapping phase. When AssemblyLoadContext.LoadFromAssemblyPath is invoked, the underlying OS (particularly Windows) places a read-lock on the physical .dll file.17 Consequently, when the "LocalEndpoints.com" update service downloads a new version of the plugin, the updating mechanism cannot overwrite the physical file on disk because the OS rejects the write operation with a file access violation error.17 To bypass managed file locks, the ALC can alter its loading strategy to utilize the LoadFromStream API.17 By opening the file into a FileStream, reading its contents directly into a byte array in memory, and passing that memory stream into the CLR, the physical file is immediately released by the OS.17 This permits the updater to seamlessly overwrite the managed DLL on disk without triggering an access violation. However, this technique comprehensively fails when the plugin depends on unmanaged (native) DLLs, such as the sni.dll component required by the Microsoft.Data.SqlClient library.17 The AssemblyLoadContext does not provide an equivalent LoadUnmanagedDllFromStream API because the native OS loader (e.g., LoadLibrary on Windows) mandates a physical file path to map the native binary into the process execution space.17 To achieve true hot-reloading for native dependencies, the architecture must implement a complex "shadow copy" mechanism.17 Shadow copying involves programmatically copying the unmanaged DLL to a uniquely generated temporary directory (for example, /tmp/plugin\_v2\_xyz/) during the load cycle, and directing the ALC's LoadUnmanagedDll override to this ephemeral path.17 Because the OS lock applies exclusively to the temporary file rather than the primary deployment directory, the updater is free to overwrite the original plugin files. However, a significant limitation persists: the OS lock on the shadow-copied temporary file remains active indefinitely until the entire host process terminates.17 Consequently, continuous hot-reloading of native dependencies will result in the gradual accumulation of locked temporary files and associated memory overhead over successive reloads.17 This fundamental constraint dictates that systems requiring aggressive, continuous hot-reloading should strictly prohibit plugins from distributing unmanaged dependencies, or alternatively, shift their execution entirely to an Out-of-Process model.

Out-of-Process Isolation: Bridging Local Endpoints via IPC

Given the inherent volatility of third-party plugins—which may suffer from catastrophic memory access violations, aggressive native thread blocking, or inescapable StackOverflowExceptions that instantly terminate the entire host process—in-process ALC isolation is sometimes insufficiently fault-tolerant. The alternative is executing plugins as entirely separate, standalone child processes and bridging them to the central host application via Inter-Process Communication (IPC). In C\# networking, the concept of a LocalEndpoint is a fundamental primitive. When a Socket or TcpListener is instantiated to listen for incoming connections, the LocalEndpoint property identifies the specific local network interface and port number bound to the connection.1 By casting this abstract EndPoint to an IPEndPoint, developers extract the precise IP address and port mapping enabling communication.1 While standard TCP sockets are universally utilized for distributed networks, utilizing TCP loopback connections for local host-to-plugin integration introduces unacceptable latency, parsing overhead, and the risk of network port exhaustion.6 Operating systems provide highly optimized native IPC technologies designed specifically for same-machine communication, offering massive throughput by bypassing the standard OSI network stack entirely.6 Modern.NET platforms provide native, built-in support for IPC via two primary transports: Unix Domain Sockets (UDS) and Named Pipes.6

Implementing gRPC over IPC Transports

To construct a robust communication schema between the central app and the Out-of-Process plugins, gRPC serves as the optimal contract-driven Remote Procedure Call (RPC) framework.6 By defining strict .proto definitions, both the host and the plugin establish a binary-serialized, bidirectional streaming channel that abstracts the underlying transport complexity.6 Built-in support for Named Pipes in ASP.NET Core was formally introduced in.NET 8, streamlining what previously required third-party libraries like GrpcDotNetNamedPipes.6 When dynamically launching a plugin process, the host application dictates the IPC local endpoint dynamically based on the underlying OS. Using the Kestrel web server, the configuration seamlessly routes between Named Pipes and UDS based on runtime evaluation 6:

C\# var builder \= WebApplication.CreateBuilder(args); builder.WebHost.ConfigureKestrel(serverOptions \=\> { if (OperatingSystem.IsWindows()) { serverOptions.ListenNamedPipe("LocalEndpoints\_PluginPipe\_XYZ"); } else { var socketPath \= Path.Combine(Path.GetTempPath(), "plugin\_socket\_xyz.tmp"); serverOptions.ListenUnixSocket(socketPath); } serverOptions.ConfigureEndpointDefaults(listenOptions \=\> { listenOptions.Protocols \= HttpProtocols.Http2; }); });

To achieve high-performance message throughput without the necessary multiplexing overhead of HTTP/2 over gRPC, developers may also leverage highly optimized binary IPC pipelines. Libraries such as MessagePipe provide high-performance in-memory and inter-process messaging using dependency-injection first principles.24 ServiceWire offers a lightweight RPC library utilizing fast serialization over Named Pipes.24 For absolute maximum throughput, Cloudtoid Interprocess relies on shared memory-mapped files combined with ultra-fast serialization mechanisms like MemoryPack, completely bypassing stream latency, though it requires more manual state management.24

Securing the IPC Boundary

Because the IPC transport serves as the execution boundary, securing it against local privilege escalation is paramount. An untrusted or hijacked local process must not be permitted to connect to the host's IPC endpoint and inject malicious data or command structures.6 On Windows environments using Named Pipes, the system integrates directly with the OS's access control model.6 A severe security vulnerability occurs through a mechanism known as "Token Impersonation." Named pipes inherently allow a server to execute code using the security privileges of the connecting client.6 If a highly privileged host process connects to a malicious plugin acting as a server, the plugin could impersonate the host to gain administrative system-level access. Consequently, it is a mandatory security control that all IPC connections restrict impersonation by explicitly configuring TokenImpersonationLevel.None or TokenImpersonationLevel.Anonymous when establishing the stream.6 Conversely, to validate that the client process attempting to connect is indeed the authorized host, the client can utilize the SecurityIdentifier class to verify the exact user account ownership of the pipe connection before transmitting sensitive initialization payloads.6 For UDS on Linux and macOS, security is managed exclusively by tightening the chmod and chown file permissions on the .tmp socket file, restricting read and write capabilities strictly to the user account executing the primary host process.6

Decentralized Distribution: The "LocalEndpoints.com" Store Architecture

To fulfill the requirement of a custom "LocalEndpoints.com" plugin store, the application must establish a standardized format for plugin packaging, manifest validation, and distribution over standard HTTP(S) channels. The centralized nature of the store requires a predictable ingestion pipeline that can validate metadata, versioning, and dependencies before offering the package to client nodes.

Structuring the Package Container

Rather than engineering a proprietary binary archive format, a robust framework will adapt the ubiquitous NuGet packaging standard (.nupkg).25 Architecturally, a .nupkg file is fundamentally a standard ZIP archive following specific internal directory conventions, containing compiled managed assemblies (.dll), static assets, and an XML-based metadata manifest known as the .nuspec file.25 By adhering to this standard, the plugin store infrastructure can leverage existing MSBuild targets (msbuild \-t:pack or dotnet pack) directly within the plugin developer's CI/CD pipeline, drastically simplifying the authoring experience.25 The .nuspec schema dictates the inclusion of critical metadata—such as the unique plugin ID, semantic versioning strings, author definitions, and internal framework dependencies—which the central store parses and indexes into a highly searchable database.26

Manifest Validation via JSON Schema

For highly customized environments where the XML .nuspec format is deemed too rigid or poorly suited for modern web-stack consumption, the plugin manifest can be adapted into a manifest.json embedded within the archive. The central "LocalEndpoints.com" ingestion engine must rigorously validate this JSON document before permitting the plugin into the store repository. This validation is effectively accomplished using the JSON Schema specification.27 By defining a strict JSON Schema, the ingestion engine uses parsing libraries such as Newtonsoft.Json.Schema or JsonSchema.Net (which integrates natively with the modern System.Text.Json namespace) to validate the document structure programmatically.27 The schema ensures that required properties, precise data types, and specific formats are adhered to, guaranteeing that the host application on the client machine will never crash attempting to deserialize a malformed manifest during the extraction and reflection phase of the plugin load sequence.27

Cryptographic Verification and Zero-Trust Execution

The most critical vector of vulnerability in any dynamic plugin-based application is the supply chain. If an attacker compromises the "LocalEndpoints.com" server infrastructure or intercepts the network traffic during a plugin update download, they could deliver a payload of malicious executable code directly into the ALC of the host application. Because the AssemblyLoadContext does not inherently provide any security sandboxing, cryptographic verification serves as the ultimate and mandatory line of defense.3

Digital Signatures and Public Key Infrastructure (PKI)

To guarantee data integrity and establish definitive authenticity, the plugin store architecture must enforce cryptographic digital signatures using asymmetric public-key cryptography algorithms.29 The operational flow dictates a stringent chain of custody:

1. The plugin developer signs the compiled .zip or .nupkg archive using their private key before uploading it to the central store.30
2. The "LocalEndpoints.com" infrastructure independently verifies this developer signature, counter-signs the package utilizing a centralized organizational authority key, and applies a timestamp to the transaction.30
3. The host application running on the client machine downloads the updated package.
4. Before the package is extracted or passed to the AssemblyLoadContext for instantiation, the host utilizes a pre-installed public key to mathematically verify the package signature.31

If the signature fails mathematical validation, the host must instantly quarantine the package, drop the payload from memory, and log a severe security violation, effectively preventing the execution of altered code.

Selecting the Cryptographic Algorithm: RSA vs. ECDSA

Historically, XML digital signatures (XMLDSIG) and binary software packages relied heavily on the RSA (Rivest–Shamir–Adleman) encryption algorithm.31 In.NET, this is facilitated via the RSACryptoServiceProvider or the modern RSA.Create() APIs, which leverage PKCS\#1 padding formats.29 However, RSA keys rely on the mathematical difficulty of integer factorization and therefore require significant bit lengths (for example, 4096 bits) to remain resistant to modern computational cryptanalysis.32 This inflates the size of the signature headers and slows down verification times, particularly on constrained edge devices. Modern, highly optimized plugin systems have largely migrated away from RSA to ECDSA (Elliptic Curve Digital Signature Algorithm).34 ECDSA utilizes the algebraic structure of elliptic curves over finite fields to provide identical security with drastically smaller key sizes. For instance, the commonly used P-256 curve (which adheres to the equation [Figure omitted from source export] modulo a profoundly large prime number) provides the exact same cryptographic security level as a 3072-bit RSA key while consuming merely 256 bits.34

Implementing Verification in.NET

The implementation of signature validation in C\# requires synthesizing hashing algorithms with the asymmetric public key. When verifying a downloaded payload, the archive file is first hashed using a secure algorithm such as SHA-256.29 The resulting hash is then mathematically validated against the provided signature using the public key.35 If the application utilizes the native System.Security.Cryptography namespace, the verification is highly performant using the VerifyData span-based APIs, which accept ReadOnlySpan\<Byte\> representations of the payload to minimize memory allocations.35 However, integrating PEM-formatted keys generated from external OpenSSL systems often requires parsing complex standard PKCS\#8 or X.509 ASN.1 structures.32 In complex multi-platform environments, software architects frequently integrate third-party cryptographic providers such as BouncyCastle.36 BouncyCastle provides extensive utilities, allowing for deeply customized extraction of the public key parameters using a PemReader to yield an AsymmetricKeyParameter object.33 This object is subsequently loaded into a PssSigner or ECDsa verifier to approve the binary hash.33 A profound architectural insight regarding trust validation is that it must occur entirely in memory, immediately preceding the extraction sequence. The downloaded artifact must be ingested into a temporary byte array or a read-only stream. The cryptographic engine verifies the stream directly. Only upon a cryptographic boolean true return is the stream persisted to the local plugin cache and subsequently fed into the AssemblyDependencyResolver and PluginLoadContext.

Strategic Conclusions

Engineering a comprehensive, secure plugin architecture utilizing a central update service like "LocalEndpoints.com" requires navigating the intricate depths of the.NET runtime, memory management APIs, and cryptographic security models. The architectural synthesis yields several fundamental design mandates: The choice of isolation methodology fundamentally dictates system resilience. While the AssemblyLoadContext offers lightning-fast, seamless memory access by carefully configuring shared contract types and resolving local dependency arrays, it inherently leaves the host process vulnerable to unrecoverable memory leaks and critical plugin failures. Architectures demanding extreme isolation and crash resilience should encapsulate plugins as separate processes connected via high-performance IPC mechanisms like Unix Domain Sockets or Named Pipes, prioritizing operational security over in-memory invocation speed. Furthermore, realizing the goal of zero-downtime hot-reloading demands sophisticated file-system workarounds. Due to the operating system's native handling of file locks, achieving hot-reloading requires reading managed DLLs strictly through memory streams rather than physical paths. The inability to dynamically swap locked unmanaged (native) dependencies necessitates aggressive shadow-copying into ephemeral temporary directories, highlighting the strategic reality that native dependencies should be minimized or strictly prohibited in highly dynamic, hot-swappable plugins. Finally, decentralized distribution requires absolute cryptographic trust. A central plugin store creates a massive external surface area for arbitrary code execution. Utilizing standard package formats combined with strict JSON schema manifests creates a scalable, automated ingestion pipeline. However, cryptographic verification remains the critical mechanism preventing system compromise. Implementing highly efficient ECDSA algorithms ensures robust, high-performance payload validation, guaranteeing that the local application environment never executes a payload that has not been explicitly authorized and cryptographically signed by the central authority.

Works cited

1. TcpListener.LocalEndpoint Property (System.Net.Sockets) | Microsoft Learn, accessed July 6, 2026, https://learn.microsoft.com/en-us/dotnet/api/system.net.sockets.tcplistener.localendpoint?view=net-10.0
2. Socket.LocalEndPoint Property (System.Net.Sockets) | Microsoft Learn, accessed July 6, 2026, https://learn.microsoft.com/en-us/dotnet/api/system.net.sockets.socket.localendpoint?view=net-10.0
3. AssemblyLoadContext Class (System.Runtime.Loader) | Microsoft Learn, accessed July 6, 2026, https://learn.microsoft.com/en-us/dotnet/api/system.runtime.loader.assemblyloadcontext?view=net-10.0
4. About AssemblyLoadContext \- .NET \- Microsoft Learn, accessed July 6, 2026, https://learn.microsoft.com/en-us/dotnet/core/dependency-loading/understanding-assemblyloadcontext
5. Unloading Assemblies in .NET \- Seekatar, accessed July 6, 2026, https://seekatar.github.io/2022/09/04/unloading-assemblies.html
6. Inter-process communication with gRPC | Microsoft Learn, accessed July 6, 2026, https://learn.microsoft.com/en-us/aspnet/core/grpc/interprocess?view=aspnetcore-10.0
7. GitHub \- natemcmaster/DotNetCorePlugins: .NET Core library for dynamically loading code, accessed July 6, 2026, https://github.com/natemcmaster/DotNetCorePlugins
8. Create a .NET Core application with plugins \- Microsoft Learn, accessed July 6, 2026, https://learn.microsoft.com/en-us/dotnet/core/tutorials/creating-app-with-plugin-support
9. Implementing True Plugin Isolation with AssemblyLoadContext in .NET \- Lessons Learned & Architecture Decisions : r/dotnet \- Reddit, accessed July 6, 2026, https://www.reddit.com/r/dotnet/comments/1teefa5/implementing\_true\_plugin\_isolation\_with/
10. Resolve dependencies when loading an assembly in .NET Core \- Stack Overflow, accessed July 6, 2026, https://stackoverflow.com/questions/47281663/resolve-dependencies-when-loading-an-assembly-in-net-core
11. .NET Core Plugins: Prise 1.2.3 (as easy as) | by Maarten Merken \- Medium, accessed July 6, 2026, https://maartenmerken.medium.com/net-core-plugins-prise-1-2-3-as-easy-as-f08f825fd90f
12. Prise, A .NET Plugin Framework, accessed July 6, 2026, https://merken.github.io/Prise/
13. .NET Core plugin system : r/csharp \- Reddit, accessed July 6, 2026, https://www.reddit.com/r/csharp/comments/xt1788/net\_core\_plugin\_system/
14. Debugging assembly unloadability in .NET 5 \- Stack Overflow, accessed July 6, 2026, https://stackoverflow.com/questions/71500090/debugging-assembly-unloadability-in-net-5
15. AssemblyLoadContext.Unload silently fails to unload Assemblies, leaking filehandles · Issue \#44679 · dotnet/runtime \- GitHub, accessed July 6, 2026, https://github.com/dotnet/runtime/issues/44679
16. AssemblyLoadContext Will Not Unload \- Stack Overflow, accessed July 6, 2026, https://stackoverflow.com/questions/71343636/assemblyloadcontext-will-not-unload
17. Is it possible to hot reload unmanaged DLLs? · Issue \#118 ... \- GitHub, accessed July 6, 2026, https://github.com/natemcmaster/DotNetCorePlugins/issues/118
18. Real Plugin Systems in .NET: AssemblyLoadContext, Unloadability, and Reflection‑Free Discovery | by Jordan Rowles, accessed July 6, 2026, https://jordansrowles.medium.com/real-plugin-systems-in-net-assemblyloadcontext-unloadability-and-reflection-free-discovery-81f920c83644
19. Question about Assembly loading & Resolving · Issue \#62391 · dotnet/runtime \- GitHub, accessed July 6, 2026, https://github.com/dotnet/runtime/issues/62391
20. Managed assembly loading algorithm \- .NET Core \- Microsoft Learn, accessed July 6, 2026, https://learn.microsoft.com/en-us/dotnet/core/dependency-loading/loading-managed
21. Shadow Copying Assemblies \- .NET Framework \- Microsoft Learn, accessed July 6, 2026, https://learn.microsoft.com/en-us/dotnet/framework/app-domains/shadow-copy-assemblies
22. C\# Discover the LocalEndPoint AddressFamily port number \- Stack Overflow, accessed July 6, 2026, https://stackoverflow.com/questions/1760701/c-sharp-discover-the-localendpoint-addressfamily-port-number
23. cyanfish/grpc-dotnet-namedpipes: Named pipe transport for gRPC in C\#/.NET \- GitHub, accessed July 6, 2026, https://github.com/cyanfish/grpc-dotnet-namedpipes
24. How should IPC be handled in .NET Core? \- Stack Overflow, accessed July 6, 2026, https://stackoverflow.com/questions/58549763/how-should-ipc-be-handled-in-net-core
25. Create a package using the nuget.exe CLI \- Microsoft Learn, accessed July 6, 2026, https://learn.microsoft.com/en-us/nuget/create-packages/creating-a-package
26. nuspec File Reference for NuGet \- Microsoft Learn, accessed July 6, 2026, https://learn.microsoft.com/en-us/nuget/reference/nuspec
27. Newtonsoft.Json.Schema 4.0.1 \- NuGet, accessed July 6, 2026, https://www.nuget.org/packages/newtonsoft.json.schema/
28. JsonSchema.Net 9.2.2 \- NuGet, accessed July 6, 2026, https://www.nuget.org/packages/JsonSchema.Net
29. Cryptographic Signatures \- .NET | Microsoft Learn, accessed July 6, 2026, https://learn.microsoft.com/en-us/dotnet/standard/security/cryptographic-signatures
30. Re-enabling signed NuGet package verification \- GitHub, accessed July 6, 2026, https://github.com/dotnet/designs/blob/main/accepted/2021/signed-package-verification/re-enable-signed-package-verification.md
31. How to: Verify the Digital Signatures of XML Documents \- .NET \- Microsoft Learn, accessed July 6, 2026, https://learn.microsoft.com/en-us/dotnet/standard/security/how-to-verify-the-digital-signatures-of-xml-documents
32. Verifying RSA signatures using .NET and C\# \- Simon Morgan, accessed July 6, 2026, https://sjm.io/blog/rsa-file-signing/
33. C\# (.NET 4.8) \- Verify signature using Public Key \- Stack Overflow, accessed July 6, 2026, https://stackoverflow.com/questions/78830354/c-sharp-net-4-8-verify-signature-using-public-key
34. ECDSA and Custom XML Signatures in .NET, accessed July 6, 2026, https://www.scottbrady.io/c-sharp/ecdsa-xml-dotnet
35. ECDsa.VerifyData Method (System.Security.Cryptography) \- Microsoft Learn, accessed July 6, 2026, https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.ecdsa.verifydata?view=net-10.0
36. ElectronicSignature 1.0.2 \- NuGet, accessed July 6, 2026, https://www.nuget.org/packages/ElectronicSignature
37. Validate ECDsa with SHA256 Signature in .NET \- Stack Overflow, accessed July 6, 2026, https://stackoverflow.com/questions/78680146/validate-ecdsa-with-sha256-signature-in-net
38. C\#. Electronic signature and BouncyCastle library | by Askhat Pazylidinov \- Medium, accessed July 6, 2026, https://medium.com/@stivendrak666/c-electronic-signature-and-bouncycastle-library-8e21870716e5