There could be multiple reasons why the DLL cannot load when you move a simconnect client from one machine to another. The one's I've run into thus far are:
1) different version of the C libraries (FSX was compiled with 8.0) - the current release in VS2008 is 9.0 and that's not always installed on the client PC.
2) different version of simconnect DLLs (RTM, SP1, SP2 and ESP), or no version at all (not installed).
3) different behavior when running in-process (dll) vs out of process (exe), likely because of the load context setup by the loading process. The symptom is the program works great as a standalone, yet cannot find a dependency when running in-process.
The best way I found is to manually scan the side by side folders to ensure what I need to load is in there (in fact, installed or not). Actually, it's also the only way I know to find out what version the client has installed. I then either use the context libraries to load the right side by side dll, or I use the full path to the side by side shared that I found during my scan if the host process interferes with that load. By making the manifest load manual instead of automatic, much better control of what version of simconnect you run is achieved (this means, you create your own manifests as resources, and don't allow simconnect to auto-load the manifest). Also, you don't need the simconnect.lib when you do this. That is a lot of work that should be in theory unnecessary, as it was precisely to avoid these issues that side by side was created. Also, I found that when the full path is used, it works all the time. It's safe to do so if you scan the side by side folders, as they are in a fixed location (%system%\winsxs) and the folder names are in a known format. You can verify the files you need are there, and also load their version information to confirm what is, or is not installed. The registry doesn't really help in this case - raw folder scan seems quick and efficient, and in readonly mode, doesn't get into permissions problems on Vista.
Also, I don't compile my code with MFC as a static library as it bloats my DLL by quite a bit and didn't find it necessary to do so across clients. So long as you redistribute the correct c++ runtime libraries with your add-on (that's a redist package from MS downloadable or you can include it in your setup program, it's also found in the redist folder in your visual studio install), you should be able to do without and keep your footprint small.
Simconnect needs the c++ runtime library 8.0 as well, and that's in the .msi provided with the SDK (Deluxe version only) it looks like. However, the EULA prevents you from redistributing the simconnect client unfortunately so there is no way to ensure the client is configured correctly. That's why I had to ensure it's setup on the machine first as my dll loads. To add insult to injury, FSX doesn't give great error messages as to why the dll didn't load, and neither does the operating system by the way. You have to dig very deep into the side by side fusion logs to see what's going on, or use dependencywalker. Even then it's a mind twister sometimes.
Hope this helps,
Etienne
