Stuffing SharpDX and OpenTK in different game engine implementing assemblies?

Question

I want my C# engine to give the user the choice between using Direct3D or OpenGL. My engine internally is designed like this abstracted example for a shader class:

internal class Shader
{
    private IShaderImplementation _implementation;

    internal Shader(ShaderType type, string code)
    {
        switch (Engine.GraphicsInterface)
        {
            case GraphicsInterface.Direct3D:
                _implementation = new Direct3DShader(type, code);
                break;
            case GraphicsInterface.OpenGL:
                _implementation = new OpenGLShader(type, code);
                break;
            default:
                throw new UnsupportedInterfaceException("Shader");
                break;
        }
    }

    internal void Compile()
    {
        _implementation.Compile();
    }
}

I thought this is a good design pattern. (I also prefer calling constructors over factory methods as you might have noticed, but that's just a side thing).

However:

• I don't want to stuff OpenTK (for OpenGL stuff) assembly references together with SharpDX (for Direct3D stuff) assembly references in one class library. I don't even know if that is a good idea. From the current design this would be required as the Direct3DShader and OpenGLShader classes reference D3D or OGL methods directly. Wouldn't I need to ship out both OpenTK / SharpDX assemblies even if the user only wishes to use OpenGL for example?
• I'd prefer to have one main assembly containing only the general interface stuff as seen above (let's say "Awful.Engine.dll", and another one for only OpenGL stuff ("Awful.Engine.OpenGL.dll"), another one for Direct3D stuff ("Awful.Engine.Direct3D"). But how can this be referenced in the main assembly? As you can see I have an enumeration of interfaces, this wouldn't work anymore.

Asking in a more general form, how can my main assembly interfaces and classes get implemented and extended in sub assemblies?

PS: I've heard about reflection about which I know a cent or two, and then the managed extensibility framework, but I have not figured out how it can fit into my design.

Answer 1

Design it as 3 Class Libraries for your graphics and sound layers.

Class Library 1: The interface layer

• Contains all of the wrappers and interfaces that your wrappers will implement.
• Design the interfaces to work in their own application domain and pass out interfaces for everything.

Class Library 2 (OpenTK):

• References Class Library 1 and OpenTK.
• Add a sound API like OpenAL.
• Implement your interfaces that wrap calls to OpenTK and playing sounds.

Class Library 3 (SharpDX):

• References Class Library 1 and Sharp DX.
• Implement your interfaces that wrap calls to SharpDX and play sounds through SharpDX.

Game Code

• Add a hard reference to Class Library 1, so you have all the interface types, enumerations, etc.
• Dynamic Load Class Library 2 or Class Library 3 with reflection.
• Create a new application domain for your hardware layer.
• Use AppDomain.Load to load either Class Library 2 or 3.

• Once the hardware assembly is loaded and you have the Assembly object, use reflection to get references to your interfaces, maybe something like this:

  // Making up this pseudo code
  GameApi gameApi = (GameApi)hardwareAsm.GetType(GameApi).GetMethod("Initialize").Invoke();
  
  TheGame gameWorld = gameApi.CreateGame(...);
  gameWorld.ResolutionChanged += Resolution_Changed(...);
  gameWorld.Terminated += Terminated(...);
  gameWorld.KeyDown += Key_Down(...);
  // etc....
  gameWorld.Start();
  

The benefit's of having the entire layer run in it's own application domain are numerous:

• Application Domains can be unloaded, causing any assemblies they loaded to also be unloaded. (This will be required if a user can switch from DirectX to OpenGL at runtime, which would be neat and possible, and something I've never seen anyone do before).
• Application domains can be secured with their own security descriptors, ACE's, etc. E.g. you can prevent code running in an application domain from having access to create files, make internet requests, etc. (Very useful if you are designing a plugin layer for game addons).
• Application domains can be written to be able to crash gracefully, log their crashes, and restart themselves without compromising the root process.