Exe not running

Try

I have created a project. I have taken the EXE from Release and tried to run in a system that doesn't have Visual Studio. Its running in some systems and in some systems it's not. Do I need to install anything? Please help me. Thanks in advance.

toxcct

it is complaining at some dlls missing, isn't it ? then either provide those DLLs with your exe, or compile with statically linked MFC.

Don't know where to start ?
Refer the Forums Guidelines and ask a friend

[VisualCalc 3.0][Flags Beginner's Guide]

Try

Nothing happens, when I click on the exe. It does not give any error message. Even its not there in Processes in Task Manager.

toxcct

how the different system differ ? also, maybe this[^] article may be worthing it to be read ;)

Don't know where to start ?
Refer the Forums Guidelines and ask a friend

[VisualCalc 3.0][Flags Beginner's Guide]

KarstenK

It depends which dlls your exe needs. For exe with VS 2005 you need to install the VS 2005 Runtime. There is a vcredist_x86.exe in the VS directory. This exe installs the runtime.

Greetings from Germany

realJSOP

You're assuming he's writing in C++/CLR... He hasn't actually said that.

"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001

prasad_som

Use dependency walker to identify dpendent dlls, and make sure , they are shipped on target machine.

Prasad Notifier using ATL | Operator new[],delete[][^]

David Crow

Make sure the libraries you've linked with, both explicitly and implicitly, are present on the target machine.

"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15

"Judge not by the eye but by the heart." - Native American Proverb

Try

I used "depends.exe". I came to know that msvcp71d.dll and msvcr71d.dll are missing. Its working now. Thanks everyone.

prasad_som

MaHeSG wrote:

msvcp71d.dll and msvcr71d.dll

These are debug versions of dlls, run dependecy walker on release version of your exe and find appropriate version of dlls.

Prasad Notifier using ATL | Operator new[],delete[][^]

nullable type

vcredist_x86.exe installs the c/c++ runtime + mfc dll's. This is needed for apps written with VS2005 and VC8. It has nothing to do with managed (.NET) or not! Simon

David Crow

MaHeSG wrote:

I came to know that msvcp71d.dll and msvcr71d.dll are missing. Its working now.

You cannot distribute these "debug" files. In your initial post you said that, "I have taken the EXE from Release..." Is this not the case?

"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15

"Judge not by the eye but by the heart." - Native American Proverb

realJSOP

Well duh... I was pointing out that the original poster didn't say which he was using...

"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001

malaugh

You may have other problems, but you definitely need static linking. Go to project->settings Click on the general tab Select "use MFC in a static library" press OK Select build->rebuild all

Mark Salsbery

I'm not sure why static linking is usually the suggested solution to this problem Static linking is not always desired, and in many instances impossible (eg MFC extension DLLs). Properly deploying an application is (IMO) necessary. It's documented... Deployment (C++)[^] Mark

Nish Nishant

John Simmons / outlaw programmer wrote:

You're assuming he's writing in C++/CLR... He hasn't actually said that.

I don't think he assumed that, John. vcredist_x86.exe is not about the CLR. It installs the latest MFC, ATL, and CRT DLLs.

Regards, Nish

Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. (*Sample chapter available online*)

David Crow

malaugh wrote:

but you definitely need static linking.

Why would you suggest this, when it's obvious that he has built a 'debug' version of the application? The problem is the 'debug' DLLs are not present, nor should they be, on the target machine.

"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15

"Judge not by the eye but by the heart." - Native American Proverb

malaugh

Exactly my point. If you use static linking, then you can run the program on the other machine without the other machine needing the DLLs, just copy across the exe.

David Crow

malaugh wrote:

If you use static linking, then you can run the program on the other machine without the other machine needing the DLLs, just copy across the exe.

One of the most common problems with statically linked DLLs is that the version of MFC they linked with assumed a latest-version of some other DLL, and when that DLL is not installed, either their program can't load, or if it does, it ends up with the wrong version of the other DLL and crashes or otherwise malfuctions. Common controls, Common Dialogs, and OLE are the most common points of mismatch. And there's nothing that can be done other than doing a proper install. There are about a dozen versions of MFC42.DLL, and while most of them are backward compatible, you cannot link something with a modern MFC42.DLL and expect it to work with an older one. MFC is rarely the key problem; a new version of MFC42.LIB assumes contemporary versions of a lot of other DLLs, such as common controls, OLE, COM, etc. and therefore static linking has done nothing other than increase the DLL size but not solve any problems; and you cannot use such a DLL with any MFC executable anyway, so it doesn't do any good for distributing DLLs.

"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15

"Judge not by the eye but by the heart." - Native American Proverb