After compile-run at least once an exe file is created in the debug folder.. Copying this file to a different PC won't execute, any reason for this?
After compile-run at least once an exe file is created in the debug folder.. Copying this file to a different PC won't execute, any reason for this?
Yes, the reason is that the debug C runtime library is not distributed (and I believe it's not even legal to distribute, but I'm not even 75% sure of that). When distributing your code, you should do so with a release build, not a debug build. You may still need to have certain DLL's installed on the other machine or link statically (so it is not relying on DLL's).
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
The "blocks" problem may be due to your source (bad code).
And if the compile suceeds, the EXE will generally be in your_project_dir\Release folder, but can be changed. If you go into project settings, look at the output directory. That's where your executable likely will end up.
This happens only when i change from debug to release... Compiling on this mode gives this warning
This could be part of the problem in displaying blocks rather than proper characters... In my settings, i use Multi-code...Code:ofn.lpstrFilter = "Binary Files (*.dat)\0*.dat\0All Files (*.*)\0*.*\0"; // Warning 1 '=' : incompatible types - from 'char [48]' to 'LPCWSTR' char szFileName[] = "blah blah"; WriteToFile(hwnd, szFileName); // Warning 2 incompatible types - from 'char [260]' to 'LPCTSTR' // WriteToFile(...., LPCTSTR fname);
Debug and Release are two different kinds of build. Specifically so that you can for example use macros and asserts in while you're writing code, but automatically remove them when you build the release version.
I once saw a project where they had their own version of malloc linked into the Debug version to spot memory problems. When they switched to the Release version all the debug trace was removed at the flip of a switch.
QuantumPete
"No-one else has reported this problem, you're either crazy or a liar" - Dogbert Technical Support
"Have you tried turning it off and on again?" - The IT Crowd
It will (normally) tell you which DLL's are missing, so that's what you need to install.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Anything after MSVC 2003 will NOT tell you which DLLs it cannot find. It will say the program failed to run because the application configuration was incorrect. The admin logs will tell you it's a side-by-side assembly error. Simply put - the code is attempting to use functions in a DLL but the DLL cannot be found or the code links to the wrong version of the DLL. Usually wrong versions will result in an error something like 'The value of ESP was not preserved across a function call.'
The only ways I've found to take any code compiled from MSVC 2005 + to another system and run it is to either completely rebuild it or create a setup and deployment project that creates a setup program so it can be installed on other computers. I've tried other ways and usually it takes 30 min to 1 hour to get the code to finally run correctly. Just ran into this today as a matter of fact.