Question

I’m developing a framework which allows to define what I call a presentation for an arbitrary object – you may understand such presentations as an aspect of an object. For example: objects of a certain application should be visualized by a render engine. Instead of extending the type of the object itself, you provide a presentation supplied by a service (the render engine) that reads data from the object (and may write data to in the context of other presentations).

The framework expect some interfaces to be implemented by application types in order to use the functionality. However, if the application does not provide implementations for those interfaces, the framework is automatically subclassing the type and adds default implementations for those interfaces, like this:

The framework (Managed C++):

namespace Spoc::Claire
{
  public interface class IEntity
  {
    void DoSomething() ;
  } ;
} 

Here’s a simple application (C#):

namespace Spoc.Samples
{
  class Hello
  {
    public Hello()
    {
      Console.WriteLine("Hello world") ;
    }

    static void Main(string[] args)
    {
      Entity.New(typeof(Hello)) ; // creates the "Hello" object within the context of the framework
    }
  }
}

What the framework creates by reflection within a dynamic assembly is:

namespace Internal
{
  class Hello : Spoc.Samples.Hello, Spoc.Claire.IEntity
  {
    public void Hello()
    {
      // call the base class constructor
    }
    public void DoSomething()
    {
      // default implementation for IEntity
    }
  }
}

This object is returned to the application and because of inheriting from the given type, it can be used without any restrictions.

So what’s the problem? All runs fine if the application defines their types as “public”. If not, like in the above described example, I’ll get an TypeLoadException from the TypeBuilder::CreateType() Method saying “Access denied for type Spoc.Samples.Hello”.

At the first look one may say: well, you’re trying to extend a private class outside its assembly. My argument is: yes, I do derive from a private class but within a dynamic assembly, that is by the way flagged with “RunAndCollect”, so it can never be saved and thus, types cannot be used elsewhere but in the current instance of the AppDomain. Theroetically I do not violate the private principle since the new type remains private and, frankly said, in a much more strict sense: private to the current instance of teh AppDomain.

I’ve played around with the friend assembly paradigm but apart from the fact that friendships do violate a strictly object-oriented design, I do hard to specify my dynamic assembly as a friend. I also found the ReflectionPermission attribute but ceased with that undergoing too.

Is anyone out there who can give me some advice?

PS: And yes, I can go a pragmatic way by saying, that every object trying to utilize the framework need to be public. Unfortunately I see a framework as a vehicle that should not necessarily limit down the possibilities of the underlying language not should it put implicit knowlegde.

Answer 1

Since I was advised to do so, I finally place my findings as an answer.

With a RefectionPermissionFlag::MemberAccess set for the AppDomain instance hosting the dynamic assembly and providing enough evidence for the assembly in order to have it run fully trusted, the the dynamic assembly should beable to invoke/set even private members/types within trusted assemblies. However it doesn’t and this is clearly stated by MicroSoft – RefectionPermissionFlag::MemberAccess isn’t functioning for dynamic assemblies.

What works is: [assembly:InternalsVisibleTo(“”)] set within the AssemblyInfo.cs of the assembly, whose private types/methods should be accessed from within a dynamic assembly. The bitter thing is, that you can’t do that for assemblies from third parties.