In the VB6 IDE...
we can compile the project by pressing Ctrl+F5 or by choosing
File->Make Exe. Is there any difference between these two procedures?
The former one seems to be a bit faster relatively.
What I want to
know is "What's difference between these two compilation procedures (if
any...) and where should I use the first one and where should I use the
second?"
Based on this external post but added here as a question since I didn't find it on SO.
VB6 compiles "on demand" by default which is what happens when you do Run > Start (or press just F5). This means that some compile errors won't reveal themselves until they are actually called at runtime - or maybe not at all if you happen to not execute a particular block of code containing an error.
But using Ctrl-F5 or "Start with full compile" causes each and every line of code to be compiled; any potential errors can be revealed and be eliminated this way.
'Make Exe...' causes a full compile followed by writing of the EXE of your project.
You can also set some options before compiling when you use 'Make Exe...'
(such as version number).
Paraphrased from here.
Related
When you try to run a program on Windows, and the loader can't find all of the required DLLs, the default behavior is to pop up a dialog box that describes the problem, including both the name of the program and the name of (one of the) missing DLLs. The process then hangs until someone clicks OK, and then exits with an error code. Here's an example of this dialog box:
Now suppose you're scripting some automated process that might fail for this reason, e.g. running CI tests after installation, where part of the point is to make sure the installer installs all the DLLs. You don't want your build workers to hang waiting for someone to click on a dialog box that's being displayed on a monitor that the computer physically does not have because it's in a server rack somewhere. You want the test cycle to stop immediately and the details to get written to the log.
Your build driver can disable this dialog box for itself and all its child processes (assuming nobody uses CREATE_DEFAULT_ERROR_MODE) by calling SetErrorMode:
SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX | SEM_NOOPENFILEERRORBOX);
hProc = CreateProcess(...);
However, this only solves half of the problem. The offending process will terminate with an exit status of 0xC0000135 (STATUS_DLL_NOT_FOUND), but the name of the problem executable and the name of the missing DLL are not reported anywhere that I can find it.
So here's the actual question: From code running in the build driver, how do I get the name of the problem executable and the name of the missing DLL, so that I can write them to my CI build logs? Anything goes, except that the code of the problem executable itself and its DLLs cannot be modified (because this is supposed to be a general solution) and an approach that does not require elevated privileges is strongly preferred.
(This is a follow-up question for Suppress "The program can't start because X.dll is missing" error popup . I've been vaguely meaning to write it for years now.)
Even though it's a little overkill, you could write a program/script that parses the PE format of each executable, walks its import table to enumerate imported modules, and checks to see if each module exists on the system (i.e. is it in \Windows\System32, the current directory, etc).
Then, if the executable in question is missing an import, log the executable and the missing import somewhere (and don't run the executable, of course).
If you want to do this in Python, the pefile module is excellent (https://pypi.org/project/pefile/).
(Update: This won't work for DLLs that are imported via LoadLibrary)
Okay, I've been struggling with this for full last couple of hours. I have a Windows 7 32-bit installation, on which I'm trying to compile some old code. I do not have any working knowledge of VB, but I'm trying to build a VB6 project which is part of the code base. The code compiles and when I run it after full-compile, it runs. But I can't seem to find where this file is. Task manager shows VB6 as process. It is not present in %TEMP%, and not in my project directory. Running an exhaustive search on my single drive configuration, I can find only one entry by this name, and this file has a timestamp older than current time. I attempted delete on this one while the debugger was still on breakpoint and it succeeded. As last resort in prefetch directory, I deleted that entry also, but magically this file still runs when on VB6. What must have been going on?
When you run an application within the VB6 IDE, it entirely runs within the VB6 IDE. Unlike some other languages, it isn't creating an executable file and then running it separately while hooking a debugger up, it just starts running your code using the VB interpreter.
To create a standalone .exe file, you need to create it separately. In the "File" menu, choose "Make projectname.exe". For full details, see "Making and Running an Executable File" in the Visual Basic 6 Concepts guide.
I'm sort of conceptually designing a plug-in I'd love to have here. What I'd want is to be a able to tag line in my code (something like how breakpoints are added) and then get a trace log of when execution runs though them. Rather than set breakpoints (because they don't work outside the debugger), I'd rather that inside the compiler, the extra logging be added so the AST.
The main point would be to compare different runs of a program; it crashes if I do A but not if I do B and most of the code should be the same so where is it diverging?
Right now I'm doing this with file IO and a diff tool; it works but is a bit clumsy.
I guess the question is: Could this be done and has something like this been done?
I don't know of anything that exactly fits your description. However...
For debugging-only use, Visual Studio 2010 has "tracepoints". These are added in the same way as breakpoints, but rather than stopping the program, they output some text to the debug output. Because they're set in the debugger, they don't affect your source code at all.
If you want to trace activity in a release build, then just add System.Diagnostic.Trace.WriteLine() calls into your code. These can be controlled using TraceSwitches, so they can be disabled by default and only turned on if you need extra information to diagnose a problem. Unlike Debug.WriteLine() calls they are included (by default) in release builds as well as debug builds. Note that these trace calls do cost a small overhead even if the traceswitch is disabled, so avoid using them in performance critical regions of your code.
I am writing a tool which can be used to make the matrix for the current performance of the project.
For that I required to get the time taken by each file to get compiled.
I tried with the following option but didn't succeed :(
Tools->Options->Proejcts & Solutions -> VC++ Project Settings -> Build Timing-> Yes
From the above option I am able to get the whole time taken to build the solution but my problem is to get for each one.
I am using VS2005
So anyone is having any idea then pls revert back ASAP....
I would replace cl.exe with a wrapper binary that takes the individual times. You'll have to write your own wrapper binary, but may consider using vsextcomp as a starting point.
This may sound like a newbie question - and it is. I'm relatively new to vs, we started using it a few months ago, and I still haven't "mentally" made the change from the command line. So, if you could help me with 2 things:
I create a new project (not a solution). He puts the files in some directory. After putting my code inside it, I click on the little green triangle (Debug, it says), and he compiles it, builds it and runs it. It works ok. Now, sometimes, I have to change only a tiny bit of code and I don't feel like getting the whole VS up just for that. How can I do that Debug thing from the command line, with the assumption I didn't change anything else.
Where do I tell him not to create a "Debug" subdirectory, not to create a HTML Build log, an object file ... and so on, generally, where can I find the settings which will help me to get as little files ... apart from my original source, and the .exe resultant one ?
I have to change only a tiny bit of code and I don't feel like getting the whole VS up just for that. How can I do that Debug thing from the command line, with the assumption I didn't change anything else.
I think what you want here is not debugging but a rebuild of your project.
Where do I tell him not to create a "Debug" subdirectory, not to create a HTML Build log, an object file ... and so on, generally, where can I find the settings which will help me to get as little files ... apart from my original source, and the .exe resultant one ?
The answer to both these questions is to use the command line! You can make VS emit a make file from the loaded project. Use NMAKE to build this make file after you have made your desired modifications. The ".obj" files are created as an intermediate step between compilation and linking phase this is how the C++ compilation model works. Why do insist on not generating them?
You can't really start debugging without starting up Visual Studio, since Visual Studio is the debugger. You can tell VS to rebuild a solution from the command line without firing up the UI if you want to just build it: See MSDN for details.
You can control the creation of the DEBUG and RELEASE directories via the 'intermediate files' option in the project settings. Though you need to create the obj file somewhere in order for the compile to work.