Optional “Library-Only” Mode for C#

[JDanielSmith]

TL;DR: Introduce an optional “library-only” mode for C#—similar to AOT—to enable lightweight, portable code without runtime overhead. This split between C# (language) and .NET (runtime) would unlock new scenarios for AI, Web (Blazor), and edge environments while preserving the full experience for most users.

---

C# has matured into a versatile language, but its reliance on a runtime limits adoption in constrained environments (e.g., iPhone/iPad). Introducing an optional “library-only” mode would allow developers to target platforms without runtime overhead while preserving the full experience for most users. With .NET 10 entering extended support and C# 15 on the horizon, now is the ideal time to draw a clearer line between C# (the language) and .NET (the runtime).

The vast majority of C# can be implemented on top of “just a library”; a full runtime is only needed for a handful of features, reflection being the most obvious. C++26 demonstrates that reflection can be achieved at compile-time, and the success of C, C++, and Swift shows that languages without mandatory runtimes remain powerful.

Making this optional—like AOT—mitigates disruption. The compiler would reject runtime-dependent code when “library-only” mode is enabled, while .NET 11 would continue to ship with the full runtime by default. Why now? AI-driven workloads increasingly demand lightweight, portable code for edge devices and specialized environments. A “library-only” C# unlocks new scenarios for AI inference on constrained hardware, embedded systems, and secure environments—without sacrificing the productivity that makes C# so loved by developers.

A minimum viable product (MVP) for C# 15 and .NET 11 could focus on the “big split” itself: introducing the optional library-only mode and enforcing compile-time checks for runtime-dependent features. Future versions of C# could then work to close the feature gap, perhaps by leveraging lessons from C++ and other languages that have successfully implemented compile-time capabilities such as reflection and advanced metaprogramming. This phased approach minimizes disruption while laying the foundation for a more portable, flexible C# ecosystem.

[CyrusNajmabadi]

What change are you suggesting be made to the language itself. It sounds likke you are proposing library changes (and potentially compiler changes) which are outside of the language.

[bbarry]

I was guessing the ask was for some sort of new TFM that maybe restricts acceptable framework types to those acceptable in AOT? Some sort of new netstandard like thing with a goal that devs could ship packages on this moniker and not be concerned about updating them when net11 or net12 come.

Doesn't sound like a language change to me.

---

I think there is a perceived problem where a library author ships a library with a dependency on say net8 and now when you are updating downstream code that depends on this library to net10 you don't know if it is compatible.

If that author just made their library target the "Just a library" TFM then you would know it is compatible ( 🫠 ). I mean clearly it worked before for netstandard allowing devs to write libraries shipping algorithms that do things efficiently on low allocation hot paths using pre-allocated slots of memory and utilizing the stack for non-allocating async calls that complete synchronously 99% of the time. The whole point of netstandard was to enable devs to create libraries that would be compatible with whatever downstream runtime the user needed them for, right?

[spydacarnage]

I'm not sure exactly what language changes would be necessary, probably something around dynamic. From the other direction: prove with a working eco-system (C#15/.NET 11) that no language changes are necessary for "library only" C#.

That's not how language design works. You don't come in with a pie-in-the-sky idea and tell the language team to prove why they don't need it - the onus is on you to prove that you do.

[CyrusNajmabadi]

probably something around dynamic.

Please be specific as to what changes you are looking for. We can discuss and determine if that change makes sense to add to the language.