SlimDX 1 is contained in a single, monolithic C++/CLI assembly. SlimDX 2 is structured differently: it is split up into both public and private DLLs. The public DLL, which will be directly referenced by client code, is written in C# and contains the definitions for all the interfaces, enumerations, et cetera. The private DLL, written in C++/CLI, contains the interface implementations and all our internal machinery.

The primary motivation for organizing the library in this fashion was to eliminate the problems with building “Any CPU” applications using SlimDX.

Managed applications built in “Any CPU” mode are essentially asking the CLR to load them as processes most-appropriate to the host machine: if you’re running on the x64 architecture, you get a 64-bit process. On x86, you’d get a 32-bit process.

For native code, however, the target architecture needs to be decided at compile-time, which is why there are distinct 32-bit and 64-bit versions of the SlimDX assembly. Unfortunately, you cannot load a 32-bit DLL into a 64-bit process.

If you’re using the copies of SlimDX that our installer places in the GAC, you can avoid running afoul of this problem by editing your .csproj. If you’re a user who prefers to reference the SlimDX DLLs themselves, you are out of luck. You have to pick a specific version to reference, and you have to set the machine type of your project to match.

By using a two-part distribution, we can ship a public assembly configured for “Any CPU” use. This assembly can detect whether 32- or 64-bit code would be more appropriate and load the correct private implementation DLL into your process.

This approach also allows us to write more of SlimDX in C#, which is far more pleasant language to work with than C++/CLI, and has a much better toolchain.

It also lets us improve the health of the code we do need to write in C++/CLI. Because of a peculiarity in how templates (not generics) interact with managed types, the presence of a template type anywhere in a class hierarchy results in a complete lack of IntelliSense support for that class hierarchy… but there’s a lot of redundant boilerplate code in SlimDX, exactly the kind of code one would like to use templates to write just once. We had to compromise and use macros to provide that code for SlimDX 1.

However, with the split-assembly approach — along with with our adoption of interfaces — the classes “polluted” by templates exist entirely in the private assembly and are never exposed by their concrete types; the lack of IntelliSense becomes a non-issue.

There is one small downside, unfortunately. Since the implementation DLL is loaded manually, clients who reference and ship private copies of SlimDX (that is, anyone not using the GAC version) will need to add or link the SlimDX implementation DLLs (and PDBs) in their .csproj files in order to allow the build system to copy those files into the directory of the built application.