What would cause a C++ .exe and .dll to only work on the machine it was built on?

I am using VS2010 and am working with this project.

http://www.codeproject.com/KB/audio-video/Asio_Net.aspx

Initially, I downloaded the demo binary and it would crash on my machine. After reading through some of the comments, it said to download the source, 开发者_JAVA百科build it, (after getting the ASIO SDK), and it should work on your machine. This is correct, after building it in VS it works, on that machine.

When I moving the rebuilt .exe and .dll to a different machine, it crashes with the same error as the originally downloaded demo binary. So I am unsure what would cause this. How can I make this C++ binary work on any machine??

I am a C# developer and most of the code is c++, so am kind of at a loss.

BTW, here is the error message:

"Unhandled Exception: System.IO.FileNotFoundException: Could not load file or ass embly 'Bluewave.Interop.Asio.dll' or one of its dependencies. The specified module could not be found.at BlueWave.Interop.Asio.Test.TestConsole.Main(String[] args)"

EDIT: Answer found here: http://msdn.microsoft.com/en-us/library/8kche8ah(v=VS.100).aspx

Use dependency walker to find which .dll is missing.

---

Assuming you mean that you've included this dll - Bluewave.Interop.Asio.dll then there only a couple of explanations I can think of:

1. One of it's dependencies is missing from the machine. You can use something like Dependency Walker to find out what's missing.
2. The dll is not in a location the exe can see (unlikely but you never know).

The missing dll may well be part of the VC++ runtime and not necessarily part of Asio.

What else is in the output folder on the machine where you built it?

---

I've downloaded that demo project from Code Project and I think the most likely cause of the problem is that the Visual Studio C++ 2008 runtime dependency is missing. Solve this by installing the runtime redistributable package on the machine.

Note: I checked the dependencies of this DLL using Dependency Walker. You can even run this in profiling mode so that it will tell you at runtime exactly which dependency is proving troublesome.