C# - Protected Internal With Real Time Use case

Protected internal Access Modifier with Real-Time Use Case in C# 

Introduction

In C#, access modifiers play a crucial role in defining the accessibility scope of types and their members. Among them, the protected internal modifier is a combined accessibility level that can sometimes confuse developers but offers very useful and flexible access control.

This article covers an in-depth explanation of the protected internal access modifier, how it behaves in different scenarios, its syntax, and practical real-time use cases to help you understand its importance and usage in professional C# programming.

What is protected internal?

The protected internal access modifier in C# means that a member is accessible either:

• From any class within the same assembly (like internal)
• Or from any derived class regardless of the assembly (like protected)

It effectively combines the privileges of protected and internal, providing wider but controlled accessibility.

How does it differ from other access modifiers?

Detailed Explanation and Behavior

Assembly vs Inheritance Scope

The protected internal member behaves like an internal member when accessed from any code within the same assembly, and like a protected member when accessed from derived classes, even if those classes are in different assemblies.

Summary of accessibility

• Any code within the same assembly can access protected internal members regardless of inheritance.
• Any derived class outside the assembly can also access the protected internal members.
• Non-derived classes outside the assembly cannot access protected internal members.

Code Example Showing Accessibility

namespace AssemblyA
{
    public class BaseClass
    {
        protected internal int protectedInternalValue = 100;

        internal int internalValue = 50;
        protected int protectedValue = 25;
        public int publicValue = 10;
    }

    public class SameAssemblyClass
    {
        public void Access()
        {
            BaseClass obj = new BaseClass();

            // Access allowed - same assembly
            Console.WriteLine(obj.protectedInternalValue);
            Console.WriteLine(obj.internalValue);
            // Console.WriteLine(obj.protectedValue); // Not accessible here, protected requires inheritance
            Console.WriteLine(obj.publicValue);
        }
    }

    public class DerivedClass : BaseClass
    {
        public void Access()
        {
            // Access allowed - inherited class
            Console.WriteLine(protectedInternalValue);  // Accessible
            Console.WriteLine(protectedValue);          // Accessible
            Console.WriteLine(internalValue);           // Accessible (same assembly)
        }
    }
}

namespace AssemblyB
{
    using AssemblyA;

    public class ExternalDerivedClass : BaseClass
    {
        public void Access()
        {
            // Access allowed because it's a derived class
            Console.WriteLine(protectedInternalValue);  // Accessible (protected internal)
            Console.WriteLine(protectedValue);          // Accessible (protected)
            // Console.WriteLine(internalValue);        // Not accessible, different assembly
        }
    }

    public class ExternalNonDerivedClass
    {
        public void Access()
        {
            BaseClass obj = new BaseClass();

            // Not accessible outside assembly and no inheritance
            // Console.WriteLine(obj.protectedInternalValue); // Error
            // Console.WriteLine(obj.protectedValue);         // Error
            // Console.WriteLine(obj.internalValue);          // Error
            Console.WriteLine(obj.publicValue);               // Accessible
        }
    }
}

Real-Time Use Case of protected internal

The protected internal modifier is useful when designing libraries or frameworks where:

• You want certain members to be accessible to all classes within your own assembly (e.g., utility classes in the same project).
• But also want to allow derived classes outside the assembly (like users extending your library) to access these members for customization.

Scenario: Building a Framework for Payment Processing

Suppose you are building a payment processing framework in an assembly called PaymentFramework. You have a base class PaymentProcessor that contains some helper methods and sensitive properties you want to expose only to:

• Any classes inside your framework assembly (for internal use).
• Derived classes outside the framework (for users who extend the payment processor).

But you want to hide these members from any unrelated, non-derived external classes.

Implementation

namespace PaymentFramework
{
    public abstract class PaymentProcessor
    {
        // Accessible within the framework assembly and derived classes outside it
        protected internal string ApiKey { get; set; }

        // Internal helper method only accessible inside framework
        internal void LogTransaction(string details)
        {
            Console.WriteLine("Logging transaction: " + details);
        }

        // Abstract method to be implemented by derived classes
        public abstract void ProcessPayment(decimal amount);
    }

    // Internal class in the framework assembly
    internal class Logger
    {
        public void Log(string msg)
        {
            Console.WriteLine("Framework Log: " + msg);
        }
    }
}

User Extending the Framework

using PaymentFramework;

namespace CustomPayment
{
    public class CustomProcessor : PaymentProcessor
    {
        public CustomProcessor()
        {
            // Accessing protected internal member is allowed here (derived class outside assembly)
            ApiKey = "CUSTOM-API-KEY";
        }

        public override void ProcessPayment(decimal amount)
        {
            Console.WriteLine($"Processing payment of {amount} using API key {ApiKey}");
            // Cannot access LogTransaction() - it's internal, not protected internal
            // LogTransaction("Payment processed"); // Error
        }
    }
}

Why protected internal works well here

• Internal classes within the framework can access ApiKey freely for core processing and debugging.
• Derived classes extending the framework from outside can also set or get ApiKey to customize behavior.
• Other external classes unrelated to payment processing or inheritance cannot access the sensitive ApiKey.

Difference Between protected internal and private protected

Since C# 7.2, private protected was introduced to restrict accessibility more than protected internal.

• protected internal: Accessible from derived classes anywhere and from any class in the same assembly.
• private protected: Accessible only from derived classes within the same assembly.

This subtle difference matters when designing libraries to tightly control access.

Example of private protected

public class BaseClass
{
    private protected int value = 10;  // Accessible only to derived classes in same assembly
}

public class DerivedInSameAssembly : BaseClass
{
    public void Show()
    {
        Console.WriteLine(value); // Allowed
    }
}

// In a different assembly, derived classes cannot access 'value'

Summary of protected internal

• Combines accessibility of protected and internal.
• Members are accessible anywhere inside the same assembly or by any derived class outside the assembly.
• Useful for library and framework design, where internal functionality and extensibility need controlled access.
• Helps expose members to trusted code within assembly and to extended code outside assembly via inheritance.

Additional Real-World Examples

Example 1: Custom UI Framework

Suppose you are building a UI control framework. The base control class contains styling and rendering helpers marked as protected internal, so:

• All controls within the UI framework can access these members.
• Developers can extend controls in their own projects and access these members through inheritance.

Example 2: Enterprise Business Logic Layer

You implement an enterprise BLL (Business Logic Layer) with internal methods shared among components in the assembly. Using protected internal members allows derived classes in other assemblies (e.g., plugins or modules) to access and override these methods.