d3dx9_42.dll

Your program requires a more recent DirectX Version than what your users have installed. There often new revisions of DirectX 9 (and 10,11) so people need to keep their DirectX up to date. The solution is the bundle your software with a recent DirectX redistributable (or DirectX web redistributable).
While you CAN bundle d3dx9_42.dll (search for it on your System, if you use 64-bit, use the one in your SysWow64 directory) into your executable directory, this is a violation of the DirectX license agreement, which requires you to use the DirectX redistributable. Did you never notice Games bundling DirectX with their installers? That's what you need to do.

You must redistribute the DLL for the Direct3D version you're using.

This DLL is usually installed into the end-user's C:\WINDOWS\System32 directory. Include the DLL with your application's installer if you currently have one, else just provide instructions for your end-users to put the DLL into the system32 directory.

You can find the DLL in the similarly named CAB file in the "Redist" subdirectory of your SDK directory (that one should start with Aug2009 if I'm not mistaken).

EDIT: @vectrexx: Thanks, I didn't actually know that little licensing bit. That's probably a good thing to know.

On the flip side, many programs DO bundle only the required DLLs and especially for a small program it's ridiculous to pack the whole 100MB DirectX redistributable, and using the Web redist can also annoy users. I haven't heard of anybody getting into trouble yet, so that's probably something to research.

Can't I just add d3dx9_42.dll to my installation like most programs do?

I wouldn't say "most" programs do that. According to the license agreement, you're supposed to use the redistributable.
EDIT: I have looked into and it seems you can strip unnessecary files from the redistributable package:
http://msdn.microsoft.com/en-us/library/ee416805%28VS.85%29.aspx
So that's what you should do.

Original post by vectrexx
it's ridiculous to pack the whole 100MB DirectX redistributable,/quote]

You can strip down DirectX installation to only required parts (dll's). This way you can get down to few MB's: http://msdn.microsoft.com/en-us/library/ee416805.aspx#ID4EYF

Alternatively you can either dynamically link to D3DX (using LoadLibrary and GetProcAddress) or compile your program against an earlier version of the SDK (versions from as far back as 2004 are still available on the MS website). Both options should work fine and will avoid the downsides of having to deal with licensing doubts and of requiring users to update their DirectX.

What's the best (freeware) tools you use to make an installation that also isntalls the directx9 package?

Quote:

Original post by ProgrammerDX Can't I just add d3dx9_42.dll to my installation like most programs do?

No - not only is it a violation of the EULA, it's also a security concern.

The reason the D3DX library was moved into a DLL was so that it can be patched via Windows Update, in case a security problem is found. If you always overwrite the version on the user's machine with your version, then you might be overwriting a newer, patched version of the DLL with a broken version. Like wise, if you put the DLL in your application's working directory, then the OS will load that one instead of the potentially patched one.

Quote:

Original post by mhagain Alternatively you can either dynamically link to D3DX (using LoadLibrary and GetProcAddress)

The fact that the OP gets an error about the DLL missing implies that they're using D3DX functions - so loading the DLL at runtime wouldn't really help - it'd just allow him to display a "nicer" message to users. However, delay loading is a better solution, since it means you don't need to manually call GetProcAddress() for every function used, and still lets you display a user friendly error.

Quote:

Original post by mhagain ...or compile your program against an earlier version of the SDK (versions from as far back as 2004 are still available on the MS website)

I'd recommend against this; newer versions of the D3DX library have several performance and security improvements over older versions.

Quote:

Original post by Evil SteveNo - not only is it a violation of the EULA, it's also a security concern. The reason the D3DX library was moved into a DLL was so that it can be patched via Windows Update, in case a security problem is found. If you always overwrite the version on the user's machine with your version, then you might be overwriting a newer, patched version of the DLL with a broken version. Like wise, if you put the DLL in your application's working directory, then the OS will load that one instead of the potentially patched one.

Though if he included his own DLLs, he'd be pretty unlikely to install them in the system folder, adding a D3DX DLL in your application folder has no effect on the rest of the system, merely prevents him from taking advantage of future updates to the dll.

Quote:

Original post by marius1930 Though if he included his own DLLs, he'd be pretty unlikely to install them in the system folder, adding a D3DX DLL in your application folder has no effect on the rest of the system, merely prevents him from taking advantage of future updates to the dll.

The application's working directory takes precedence over the system32 directory, so the DLL included with his app would be used instead of the potentially patched one in system32.

EDIT: MSDN: Dynamic-Link Library Search Order

Quote:

Original post by Evil Steve Quote: Original post by marius1930 Though if he included his own DLLs, he'd be pretty unlikely to install them in the system folder, adding a D3DX DLL in your application folder has no effect on the rest of the system, merely prevents him from taking advantage of future updates to the dll. The application's working directory takes precedence over the system32 directory, so the DLL included with his app would be used instead of the potentially patched one in system32. EDIT: MSDN: Dynamic-Link Library Search Order

Thats what i just said. it prevents HIM from taking advantage of any updates, but does not affect the rest of the system. As opposed to "overwrite the version on the user's machine with your version", which seems like an unlikely scenario. (placing it in system)

Quote:

Original post by marius1930 Thats what i just said. it prevents HIM from taking advantage of any updates, but does not affect the rest of the system. As opposed to "overwrite the version on the user's machine with your version", which seems like an unlikely scenario. (placing it in system)

Oh - whoops, I misread it.
It's still not really a good idea though, it just takes one application with a security problem to cause trouble.

Indeed. Remember the GDIPlus security flaw nightmare? Microsoft actually had to release a tool to scan the entire system for affected versions of the library.

I've detected in old games that the D3DX helper functions are embedded into the executable of the game itself and the D3DX functions are not in a seperate DLL.

That's way better, and also makes it more annoying for cheat programmers to hook those DLL functions.

Is it just security so Windows can update the DLL that the D3DX functions are placed in a DLL?

Quote:

Original post by ProgrammerDX I've detected in old games that the D3DX helper functions are embedded into the executable of the game itself and the D3DX functions are not in a seperate DLL. That's way better, and also makes it more annoying for cheat programmers to hook those DLL functions. Is it just security so Windows can update the DLL that the D3DX functions are placed in a DLL?

The D3DX library uses to be a static library before December 2004 (I think it was Dec 2004). That was a problem for the security reasons already mentioned, and it means that a simple program that uses D3DX was usually over 1MB in size because of the static library.

You already need to distribute the Visual Studio runtime with your app, it's not much more work to distribute a stripped down DirectX runtime too.

I'm not using CRT or ATL or MFC in my code, so I dont need to include the Visual Studio runtime.

Anyway I did some investigation, installng the redist is pretty simple on a client machine.

Just with using dxsetup.exe

Quote:

Original post by ProgrammerDX I'm not using CRT or ATL or MFC in my code, so I dont need to include the Visual Studio runtime. Anyway I did some investigation, installng the redist is pretty simple on a client machine. Just with using dxsetup.exe

If you're using main() or WinMain() then you're using the CRT.

Ok but that doesn't need a redistributable package