Access Modifier, Inheritance and Foreign Assembly

let's say I have a baseClass in myFramework namespace:

using System;
using System.Collections.Generic;
using System.Text;

namespace myFramework
{
    public class baseClass
    {
        internal int m_value;

        internal int getValue() {
            return m_value;
        }

        internal void setValue(int value) {
            m_value = value;
        }

    }
}

In MyApplication namespace I inherit from it:

using System;
using System.Collections.Generic;
using System.Text;
using myFramework;

namespace MyApplication
{
    class InheritedClass: baseClass开发者_JAVA技巧
    {
    }
}

In a form in MyApplication namespace I use it:

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
using myFramework;

namespace MyApplication
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }

        private void Form1_Load(object sender, EventArgs e)
        {
            InheritedClass inheritedClass = new InheritedClass();

            inheritedClass.setValue(10);
            textBox1.Text = inheritedClass.m_value.ToString();
        }
    }
}

As you can see I have declared m_value with internal modifier so that I can access it from Form.

Now what if I compile myFramework in a separate assembly ? internal won't work any more ? So is there any modifier I can use ? Protected can't even do less the job. Am I obliged to use public ?

Isn't there an access modifier that allows an object (form) which OWNS a class (inheritedclass) to access all the members of all class and parent class he owns like internal except that internal doesn't consider ownership but where the class has been declared ?

Update: of course in real world use, my base class has tight semantics with form (or view) so it's up to me to decide if I should do it, my question is not if I should do, my question is if it is possible or if I will be obliged to use stuff like Design by Contracts which I find silly to add yet another tool for such basic requirements.

---

The form does not "own" the class, the form can be said to "own" an instance of that class, but even that is rather unclear; normally we use "own" to mean "has ultimate responsibility for", in the case where an object has to be disposed or otherwise "cleaned-up" at some point.

The form has absolutely nothing to do with the inner workings of baseClass. If form needs to access a member of baseClass, it should be public. Alternatively, if a member of baseClass should be private, internal, protected or protected internal, then the form has no business dealing with it.

If you are looking to give an unrelated class access to a deliberately non-public member, something has gone wrong in your design.

---

"Ownership" has no meaning here, these are completely unrelated classes. At best you could jump through the InternalsVisibleTo attribute hoop.

---

Based on the example shown, a public property would do exactly what you need. However, if you want to keep the member hidden (and you know ahead of time exactly which assemblies will need access to it), the InternalsVisibleToAttribute will do the trick.

I use this in instances where I do not want a property to be exposed, but I need access to it for testing. In this case, I know precisely that I only want my test assembly to have access to the property and I have control over how it is used.