Okay, more info from the SlimDX folks. Looks like the error is even below the level of their code; here's their suggestions:
-----------------
The fact that the user does not have the 3.0 runtime components is interesting.
Perhaps he could install the 3.0 redist? It's here:
http://www.microsoft.com/downloads/details.aspx?FamilyID=10CC340B-F857-4A14-83F5-25634C3BF043&displaylang=en
I can guard the Debug.Write() calls with an #ifdef, which we should probably do in
the long run anyway, even though this does not appear to be a SlimDX bug
specifically. However I'd like to make sure we figure out if we can resolve it first.
----------------
Sure. He said he reinstalled the 3.5 redist, but still didn't have the 3.0
directory. I seem to recall having this issue at work as well... not this specific
issue, but one where the 3.0 redist needed to be reinstalled even though we had the
3.5 stuff on the machine and even though the 3.5 installer is supposed to include
the 2.0 and 3.0 framework components.
If he lacks that directory, he lacks some 3.0 runtime components, including the
stuff that would (ostensibly) let him fix the configuration issue. By getting him to
install the 3.0 redist, we can see if that creates the directory with the tool he
needs to run, and if running that tool fixes him.
As far as I can tell, this is not a SlimDX issue. SlimDX only requires 2.0, and the
actual failure here is deep into the runtime code, well beyond the API boundary
between SlimDX and the BCL. Although that call to Debug.Write() should not be in the
release bits of SlimDX, that itself turns out be the result of a compiler bug (the
C++/CLI compiler ignores ConditionalAttribute) but should nevertheless be perfectly
safe according the SDK documentation.
What I want to ultimately do is remove that Write() call from the release builds
manually. However, while this will appear to fix this bug, I am convinced it will
actually just be masking whatever the *real* problem is.