creating visual studio C++ setup

>> everytime I try to run the exe after installing it I get an error.
Which is?

"C:\MyProject\MyApp.exe

This application has failed to start because the application configuration is incorrect.  Reinstalling the application may fix this problem."

This application was compiled with Visual Studio 2008 Express.  It is my understanding that C++ projects built with this compiler have problems running on other machines.

I also will get this error

"The application failed to initialize properly (0xc0150002). Click on OK to terminate the application."

You are packaging a release build and not a debug build right? This is the kind of error I'd expect to see if you'd accidentally packaged the wrong version.

I had the engineer verify that it was created as a release version.  I have a copy of Visual Studio 2010 on my laptop that I plan to bring in tomorrow.  I'm thinking that maybe I might be able to do this as OneClick installation.  I'm not sure.  I don't have a lot of experience with non-VB/C# apps.  I'm just wondering what you're thoughts might be.  I also thought about using a setup project type as well.

@evilrix: please stay here. I didn't want to interrupt you. Just added a scenario I'd follow in such cases.

Maybe, the most important point :)
After the installation, manually check the your application is fully installed into the right folder: the executable, dll's, all resources are exactly in the place you wanted them to be, all the names are correct.

Just wanted to let you both know I'm having the engineer I'm working with take a look at Dependency Walker as well as the other items mentioned and I'll try to let you know what we find later in the day.

When I try to open the exe that will run the application I get errors with loading the following DLLs.

MSVCP80.DLL
MSVCR80.DLL
IESHIMS.DLL
WER.DLL

Additionally with the error log I get the following information:

Error: The Side-by-Side configuration information for "c:\program files\my application\LIBDB_SQL50.DLL" contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001).
Error: The Side-by-Side configuration information for "c:\program files\my application\LIBDB50.DLL" contains errors. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem (14001).
Error: At least one required implicit or forwarded dependency was not found.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

I've added the correct versions of msvcp80.dll and msvc80.dll to the application directory and now Dependency Walker is not logging them as an issue.  However I'm trying to work through the problem with IESHIMS.DLL and WER.DLL as well as potentially MPR.DLL.

We found out the issue was that we needed to do a seperate install with the Oracle's Berkley Database package to get the two database DLLs to work.  When we did this the application loaded.  I'm not sure how to award points.  Any suggestions?  I will say that when I saw the log information using Denpendency Walker related to the to database DLLs that raised some suspicions.  The engineer responsible for developing the application was the one who figure out to install the software.

Split the points.
http://#a33623944
http://#a33624358

Using dependency walker helped to justify potential avenues of questioning that eventually led to a solution.

>> eventually led to a solution.
Now read your question. From the information you provided there can we imagine that the problem is somewhere around Oracle? We gave you the key - Dependency Walker. "eventually"? Is it grade 'B' for us?

>>  Is it grade 'B' for us?

Actually, according to the EE guidelines B is exactly right. We (actually probably you) pointed the asker in the right direction but they will need to do more worrk.

PeterTrefren, One thing I would say is I don't think anything I posted actually helped in this regard. My answer that you've selected only affirms what pgnatyuk said. This being the case I would have no object were you to decide that he should have got all the credit in this case. Since it's your question it's entirely your call.

Finally, I -- for one -- would love to know how you eventually resolve this and I'm sure the info would be very helpful for other. Please do post back with the solution to assist others.

Thanks you kindly and the very best of luck.

I split the points on advice from pqnatyuk and awarded 'B' to both.  Hope that seems resonable.  Pqnatyuk the links you posted didn't work on my end.  I split the points evenly because both of you mentioned Dependency Walker.  Basically the issue was that the application uses a third party library for accessing the data.  This is something like when you develop an app using MySQL.  The provider of this kind library will also make available a setup package that gets installed before the application goes on.  Its difficult to impossible for something like the setup project type to know what all dependencies are for something like this because some of the late-binding issues.  I should have caught this sooner because of my experience with doing occasional MySQL setups.  It was just one of those situations where you get brought into something at the last minute and I didn't fully understand what tools had been used.   When I saw the log information about the database dlls that got me to thinking. My reasons for crediting Dependency Walker is that although the engineer figured out to use the provider setup "by himself",  I can't help thinking that part of that came from me serveral times mentioning to him that I thought the C++ app installed correctly and that the problem had to do with the database dlls.  My reasoning was driven by the fact that the app was written in VS 2008 and the support DLLs that were missing listed by Dependency Walker where ones related to VS 2005 development.  I'm referring to MSVCP80.DLL and MSVCR80.DLL.  If Dependency Walker was complaining about MSVCP90.DLL and MSVCR90.DLL, that would would make me think it was more of a problem with the application written by the developer.  

Hi PeterTrefren,

Thank you for taking the time to post back here and let us (and others) know how you eventually resolved this.

Best regards,

-Rx.