Feature Request: Allow Partial Classes to Extend Across Assemblies

[chris-briddock]

Title: Feature Request: Allow Partial Classes to Extend Across Assemblies

Problem Statement:

Currently, partial classes in C# are limited to being defined within a single compilation unit (typically an assembly). This limitation can pose challenges in scenarios where different logical parts of a class's functionality or metadata need to be managed and potentially versioned independently across different assemblies.

For example, in large, modular applications or frameworks, it can be desirable to:

• Separate core class definition from extension points or metadata defined in separate modules.
• Allow third-party libraries to provide extensions or metadata for a class without modifying the original assembly.
• Manage domain-specific aspects of a class (e.g., UI-related properties) in a different assembly from the core business logic.

The inability to extend partial classes across assembly boundaries forces developers to use less elegant workarounds, such as:

• Defining separate, non-partial classes that relate to the main class through inheritance or composition.
• Using attributes or external configuration files to associate metadata with a class defined elsewhere.
• Sacrificing modularity by consolidating related code into a single assembly.

Proposed Solution:

We propose extending the partial class concept to allow parts of a single class definition to reside in different assemblies. This would entail changes to the C# compiler and potentially the .NET runtime to enable the aggregation of partial class definitions across assembly boundaries during the compilation or loading process.

The specific mechanism for how this aggregation would work needs careful consideration, but potential approaches could involve:

• A new assembly-level attribute or configuration mechanism to declare that an assembly contains partial definitions for classes defined in other specified assemblies.
• Modifications to the .NET metadata format to link partial class parts across assemblies.
• Changes to the compiler's resolution process to discover and combine partial definitions from referenced assemblies.

Motivation/Use Cases:

The ability to extend partial classes across assemblies would offer significant benefits in various scenarios:

• Modular Development: Enables better separation of concerns and encourages the creation of smaller, more focused assemblies. Core logic can reside in one assembly, while extensions or customizations are provided in others.
• Extensibility and Plugin Architectures: Allows third-party developers or separate teams to extend existing classes with new members (methods, properties, fields) or metadata without needing access to or modification of the original assembly's source code. This is particularly valuable for creating robust plugin systems or framework extensibility.
• Metadata Management: Facilitates the separation of code and metadata. For instance, data annotations, UI hints, or other attributes specific to a particular context (like a presentation layer) could be defined in a separate assembly, keeping the core domain model clean.
• Version Management: Potentially allows for independent versioning of different aspects of a class, although this aspect requires careful consideration due to the potential for complexity.
• Code Organization: Provides a more natural way to organize related code for a single logical entity across different projects or concerns.

Considerations and Challenges:

Implementing this feature presents significant technical challenges that need to be addressed:

• Dependency Resolution: How does the compiler and runtime determine which partial parts belong to a class? What happens if only some assemblies containing partial parts are referenced?
• Member Conflicts: How are conflicts handled if the same member (method, property, field) is defined with conflicting signatures or return types in different partial parts across assemblies?
• Constructor Behavior: How would constructors be handled? Can constructors be split across assemblies?
• Versioning and Compatibility: This is a major challenge. Changes to a partial part in one assembly could break compatibility with another assembly that relies on a different version of the partial class.
• Intellisense and Tooling: IDEs and development tools would require substantial updates to correctly identify, resolve, and provide features for partial classes spanning assemblies.
• Performance: How would the aggregation of partial parts across assemblies impact compilation times and runtime performance?
• Discoverability: How would developers easily understand and discover all the parts of a partial class that are spread across different assemblies?

Alternatives Considered:

We have considered alternative approaches like using inheritance, composition, or attributes/external configuration. While these can address some of the use cases, they often lead to less intuitive code organization, require more boilerplate, or don't offer the same level of seamless integration as a language-supported partial class extension mechanism.

Conclusion:

Allowing partial classes to extend across assemblies would be a powerful language feature that could significantly improve code modularity, extensibility, and organization in complex applications. While it presents significant technical challenges, the potential benefits warrant exploration and discussion within the Roslyn community. We welcome feedback and ideas on how this feature could be designed and implemented.

Proposed Keywords for Searching: partial class, multiple assemblies, cross-assembly, modularity, extensibility, language feature, Roslyn

[HaloFour]

You can use an IL rewriter to accomplish something like this. I really don't think it belongs in the language.

[huoyaoyuan]

It will break CLR type loading massively. A type is fully determined by its assembly. Even with #9320, the allowed extension from other assembly will still be very limited.

It may be involved by sub-assembly building block (dotnet/fsharp#14300), but a type can only strictly belong to one assembly.