Shrew

Thats what got me. Thanks for pointing that one out. Now I've searched through the redist files there is the warning in "directx redist.txt" about how to install the managed DX components. It never occured to me to look in the "license" directory for installation instructions. More fool me. As to installing it for full scale apps - I think the .net framework and dx9 installed as a prerequisite are not too harsh. Personally i'm inclined to distribute the extra managed dlls along with my app. Which funnily enough is part of what the strong versioning in .net can promote. But then I expect its against the EULA of the redist package to break it up like that.

I too get the same error. I have the managed SDK installed and it works fine on my machine. All other users have installed the latest version of DX9 and the .net framework. My understanding of the .net framework suggests that Microsoft.DirectX.dll and its asoociated dlls should be resident in the users global assembly cache for the app to work. None of the users have it, so the latest DX9 redist is either not installing them or not installing them correctly. Or possibly they are not meant to be installed, and must be resident in my applications current working directory, meaning i have to distribute my particular directx.dlls with it. This works but does not seem correct. MSDN isnt too clear on the subject tbh, so Im interested in an actual respone. There must be a definitive line on how to get the dlls onto a users machine... If you havent tried running one of your c# dx apps on a machine without the sdk installed you will not have seen this behaviour. If you have got your stuff running on another machine without the sdk short of copying the dlls over manually Id be very interested. Shrew I would also like to add that the directx.log files resident on users machines make no mention of the dll, whereas those with the sdk do.