|
;Pkindly observe,
now he has modified his post, and now, it seems something relevant.
i think, by the time you saw it, he has modified it.
thats why u mis took me.
|
|
|
|
|
Then I take back all I said!
And I'm apologizing if I offended you!
|
|
|
|
|
For both...
Original post is below... still repeated :P
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
|
|
|
|
|
|
thanks,
modify your post or better delete it.
lets have a good working atmosphere at code project .com.
|
|
|
|
|
It's so because on another's computer the workarounds of yours application is different then on yours PC.
When compiling, application is compiled with other files (like .dll's for example) and it can be linked with yours application as static or shared... What I'm trying to tell you is that yours application is missing some file on another's computer to work!
Try to find out which one, or post more details here!
|
|
|
|
|
First thing you have to do is distribute the release version of your program.
Then, with your application, you need to distribute vcredist_x86.exe and execute it on the target machine. This can be found here[^]. This will install the C run-time library and the MFC libraries.
If that still doesn't work, then your application depends on other dll's that are not found. Use dependency walker to check which dll's are required to be distributed with your app.
|
|
|
|
|
I have checked my program in a computer without visual studio, with debug version crashed because how missing dlls, but release worked good. But now, with your answer.
The question is... Should the release version of a normal MFC-Win32 program work in all computers (supposing no dll is used at all)? Or better include this vcredist_x86 in all applications?
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
|
|
|
|
|
Which Compiler are you using.. since in Visual Studio 2005, you required to deploy Manifest file needed to run VC++ application !
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
VC++ 6.0
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
|
|
|
|
|
Nelek wrote: VC++ 6.0
In that case, things are even more simple: you just need to distribute your executable and the dll on which it depends. If you statically link to all the dlls, you can just distribute your exe.
|
|
|
|
|
Nelek wrote: The question is... Should the release version of a normal MFC-Win32 program work in all computers (supposing no dll is used at all)? Or better include this vcredist_x86 in all applications?
The debug version will never work, even if you run vcredist_x86.exe on the target computer (it only install the release versions of the libraries). Now, you could avoid to distribute this executable if you statically link to the C run-time library and to the MFC dll's (but I'm not 100% sure because I never tested it).
|
|
|
|
|
Cedric Moonen wrote: Now, you could avoid to distribute this executable if you statically link to the C run-time library and to the MFC dll's (but I'm not 100% sure because I never tested it).
I statically link all the time and you are correct - you do not need vcredist_x86.exe if you statically link.
Judy
|
|
|
|
|
Can you more explain some detaily of your program?
|
|
|
|
|
But a third party dll, all are things from MFC, list, objects, views... nothing really special
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
|
|
|
|
|
I want copy my new application to another computer. I have copied but there was an error when i'm clicking application. "the Application has faild to start because the Application configuration is incorrect. Reinstalling the application may fix this problem."
|
|
|
|
|
may be the program isn't compatible with the OS you are using. So i suggest to try to run the application with "run with compatibility with Win95,98,nt,..." may be it will work.
|
|
|
|
|
Hi,
I am using a 3rd party SDK to build one sample DLL application. I am using their static lib to link with my project.
During linking, I am getting the following warning message:
gdal.lib(cplgetsymbol.obj) : warning LNK4099: PDB 'vc80.pdb' was not found with '..\dev\dw32\gdal.lib' or at '..\dev\dw32\vc80.pdb'; linking object as if no debug info
There are lots of such warnings. I am using VS2005 to build my application.
In code generation I am using Multi Threaded Debug DLL (/MDd).
Can you tell me the way to remove LNK 4099 warnings and what is the cause for this?
Regards
Sunil
|
|
|
|
|
I dont know if for that, it will be the same, but I disable usual compiler warnings with
#pragma warning(disable:XXXX)
Hope it helps
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
|
|
|
|
|
Nopes it doesnt work. I have already tried that. In the Linker options, also i tried to add /wd4099 or /ignore:4099..Nothing of them worked.
|
|
|
|
|
Nelek wrote: #pragma warning(disable:XXXX)
you can disable warning .. not error!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
I told it. "usual compiler warnings"
i was referring to the second part of the intial message, not to the liner error
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
|
|
|
|
|
Your 3rd party has provided you with a release-mode lib file. The linker is correctly telling you that it can't find the debugging symbols for the library in question. This means you can't step into it in the debugger (except as assembly code). The warning will not affect your use of the library. You won't get the warnings in your release build.
|
|
|
|
|
Is reading an Inf file same as raeding a normal text file?
If no , then what all has to be done to read an inf file?
|
|
|
|
|
I think it depends on what a format it has, Binary - Text and so on..
but it should be similar about the concept.
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
