Deploying C# application that uses DirectX assemblies

2
votes

I am developing the application that uses DirectX for graphics rendering. I have to point out that I am not using XNA or SlimDX, although I probably should. However, I did not know this at the project launch, and now it's too late as it would take a lot of time to convert to any of these.

That said, I need to deploy the application to users. In my project, I have referenced the following assemblies:

  • Microsoft.DirectX
  • Microsoft.DirectX.Direct3D
  • Microsoft.DirectX.Direct3DX

I only need these assemblies, nothing else. The users are required to have DirectX installed on their computers as a prerequisite. Therefore, I found including these DirectX DLLs to my application folder or GAC unnecessary.

I am having problems with some environments while other work perfectly. I've traced the issue to whether DirectX assemblies are registered in %windir%\assembly. If there are DirectX assemblies listed here, the application runs. If there are not - it fails to launch.

The problem is that even though DirectX is installed on all computers (dxdiag works, DirectX files are listed in it), some of them do not have these assemblies listed in there. When this happens, the application fails with System.IO.FileNotFound exception:

Could not load file or assembly 'Microsoft.DirectX.Direct3D, Version=1.0.2902.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.

For instance, if the latest stand-alone installer is downloaded from Microsoft website and installed, the assemblies are registered. I am not sure about the case when they do not get installed, but it happens. Often.

My questions:

  1. Why does DirectX sometimes register these assemblies and sometimes do not?
  2. What is the proper way to reference DirectX assemblies from within the application?
2
c#deploymentdirectxassemblies
Are they the same assembly versions across machines and your development PC? – Adam
@Adam Actually, I am not sure at all. I am targeting DirectX 9 DLL's that date back to 2005. Some of users are having DirectX 11 installed (which is newer, of course) and the application fails. I assume more recent versions of DirectX should install all previous DLL versions as well, so to allow for application compatibility. If this was not the case, I'd have to reference multiple versions of assemblies. Am I right? – Nikola Malešević
From DirectX documentation it does look like each version is deployed. Have you thought about including DirectX install in your installation package. As per msdn.microsoft.com/en-us/library/windows/desktop/… – Adam
So even if they had it installed the installation would just quietly disappear, though if they didn't it would install silently then continue on. – Adam
DirectX 11's support for previous versions is down through a virtualization of sorts. If your program requires DirectX 9 then require that version, supply the version you built against on your support website, and tell users to install that version. Why are you not building against Direct X 11? – Security Hound

2 Answers

2
votes

I'm not surprised that you're seeing these issues. You're relying on an extremely old, discontinued, and no-longer-supported API. The latest runtime installers will still install the assemblies for compatibility purposes, but they're not included by default because they don't expect anyone to use them.

Honestly, they're really old (like, 10 years old), they have numerous known bugs and issues that will never be fixed, and there are perfectly acceptable replacements out there. You should either switch to one of them or resign yourself to dealing with issues like this for as long as you continue to support your app.

2
votes

I have experienced something similar with the SimConnect DLL that is part of Flight Simulator. In this case it turned out that the DLL was not added to the GAC if a user installed Flight Simulator before they installed the .Net framework.

My guess is that something similar is happening here.

This of course means that it could only occur on XP systems that do not have .Net by default and it should be fixed after a reinstall of DX after .Net has been installed.