I realize this is going to be an exotic question, but I just can't find the answer.
I'm trying to fix up and enhance an old visual basic-based application.
My problem is: where is the output directory with the compiled binaries?
Thanks.
If some clarification is needed, please ask.
In the .VBP, if there is a line specifying the path like this
Path32="C:\"
Then the resulting EXE will be built at that location. Otherwise, it will be built in the same directory as the .VBP file. The path can be relational as well and may not be a fully qualified path.
I think you want the /outdir switch. This overrides the Path32 setting in the Project file.
VB6[.EXE] [[{/run | /r}] | [/runexit] | [{/make | /m}] projectname]
[/out filename] [/outdir path] [/d const=value{[:constN=valueN]}]
[/mdi | /sdi] [{/cmd argument | /c argument}]
Options:
/run or /r projectname Tells Visual Basic to compile projectname and run it,
using the arguments stored in the Command Line
Arguments field of the Make tab of the Project
Properties dialog box.
/runexit projectname Tells Visual Basic to compile projectname and run it.
Visual Basic will exit when the project returns to
design mode.
/make or /m projectname Tells Visual Basic to compile projectname and make an
executable file from it, using the existing settings
stored in the project file.
/out filename Specifies a file to receive errors when you build using
/m or /runexit. If you do not use /out, command line
bild errors are displayed in a message box.
/outdir path Specifies a directory path to place all output files in
when using /make. This path must already exist.
/d or /D const=value... Tells Visual Basic which values to use for conditional
compilation constants when making an .EXE or ActiveX
component with the /make switch. Separate multiple
constants with colons.
/cmd or /c argument Specifies a command string to be passed to the Command$
function. When used, it must be the last switch on the
command line.
/mdi or /sdi Changes the Visual Basic environment to either Single
Document Interface (SDI) or Multiple Document Interface
(MDI) mode. Visual Basic remains in this mode until
you change it.
/? Displays a list of valid command line switches.
You may use a group name in place of projectname in any of the above switches.
Works fine here.
There is no equivalent 'bin/lib' output directory for VB6. When you compile a VB6 project, the default is to compile to the same folder as the project (vbp file). It is also possible to compile to any other folder available to the user.
Related
I will be concise.
The command FOR /F %i IN (C:\Version.txt) DO #set Version=%i works perfectly fine in cmd.exe to read the text of the file into a variable. but whenever I put that line into a prebuild event in Visual Studio it says Exited with code 255.
On http://msdn.microsoft.com/en-us/library/windows/desktop/ms681382(v=vs.85).aspx I found that 0xFF / 255 means: The extended attributes are inconsistent..
How do I use that command in a pre build event?
Many thanks.
The correct syntax is
FOR /F %%i IN (C:\Version.txt) DO #set Version=%%i
However this will not work as you epxect: VS spawns a cmd.exe process to execute build events, meaning that if you set a variable it is local to that cmd.exe only, hence the rest of your build will not have access to Version.
Luckily there are much better alternatives than batch files: if you're using VS2010 or higher, the project files are msbuild files, so to get all possible versioning things working you just create a common msbuild script to do whatever you need to do with the version (eg create a .res file if it's for C++, or modify the AssemblyInfo.cs for C#) and include it in all your projects.
I am debugging c++ console application with Visual studio. I exhausted of inserting the same input every time I debug this program. I would like to use the same input more times.
I do this without debugging in command line with command: Program.exe < 1.in
Is it possible to use debugging with standard input redirected from file???
I already tried looking in to procejt properties. I tried setting Command to $(TargetPath) < 1.in instead of $(TargetPath).
I also tried setting Command Arguments to < 1.in. Niether of these method worked.
I am using Visual Studio 2012. But this is probably same in all versions of studio.
This is a supported debugging scenario. You do have to make sure that the debugger can find the file. Leave the Command setting at $(TargetPath). A possible value for the Command Arguments setting is:
< "$(ProjectDir)test.txt"
if the input file "test.txt" is located in the project directory. Or type the full path of the file to be sure. The MSDN article that describes this feature is available here.
I just create a file called stdin.txt in the project
1) set the Build Action to Content
2) Copy to Ouput Directory: Copy if newer
Then when you build stdin.txt is copied to the same folder as the executable.
Then in project properties debug|command line arguements enter the following
< stdin.txt
There is no need to use a path macro
If you don't want to mess with the the path you can add a new file with a right click on the source files folder in the solution explorer and then paste to it the content from the wanted file. And then change the command argument to the new file name.
The debug tab of the project properties for a console application in VS2010 allows me to set command-line parameters to pass to the project whilst debugging.
I would like to set a parameter which is a path and the path is specific to each developer/machine, as it is a path which resides in the solution folder and each environment is different.
For pre- and post-build events, I can use macros such as $(ProjectDir), but I can't find a way to do this for command-line parameters - is there a way? A hack is fine, as long as it's not too awful!
Thanks
I haven't found a way to use $(ProjectDir) in the command line arguments, but you can access files contained within the project by:
Tell Visual Studio to copy specific files to the output directory by changing their "Copy to Output Directory" property.
Change your command line arguments from $(ProjectDir)/FileNeededDuringRuntime to FileNeededDuringRuntime.
This is more of a hack since it probably doesn't cover all the cases of using the variable, but it may get you by if you're just referencing a few files.
Macros can be used in command line arguments for C++ projects, see:
How to pass solution folder as parameter in command line arguments (for debug)?
You could have an empty C++ project "Set as StartUp Project" and change its "Configuration Properties -> Debugging -> Command" from "$(TargetPath)" (default for new projects) to "$(ProjectDir)..\OtherProjectRelativeDebugFolder\OtherProjectsOutputFileName.exe".
Since OtherProjectRelativeDebugFolder and OtherProjectsOutputFileName are relative and thus location independent you should be fine with that.
You said:
A hack is fine, as long as it's not too awful!
Is an empty project that produces an empty dll (unless you find a way to stop it, e.g. delete on post-build) too awful?
BTW. Environment variables aren't resolved in "Debug -> command line arguments" for C# either. I'll be experimenting on setting an environment variable, passing its name (because it isn't resolved) and reading it in the program. Passing the name is intended to show where the environment variable comes from, i.e. project settings.
Edit:
I hoped to find a way to set the environment variable to the value of a macro, e.g. in a build event. A simple shell "set" command is not persistent, so it didn't work out. Instead I was able to use a relative path as working folder to get things work for me. I also found a workaround that uses a file for persistent storage:
VS2010 - Project Macro Variables in Start Options Command Line Arguments
I'm doing batch compiling and need to specify the output directory.
/run
/runexit - Compile and then run it. Exit VB IDE when project returns to design mode.
/make or /m projectname - compiles an makes exe using the existing settings in proj file
/out filename
/outdir path Specifies a directory path to place all output files in when using /make
/d
/cmd
/mdi or /sdi
... and a couple of others.
Run vb6.exe /? for more information.
A bit of Google work suggests that such a list of options can be obtained by going to the directory containing vb6.exe in Command Prompt and running
vb6.exe /?
VB6
Information directly from running VB6.exe /?:
Command Line Options
VB6[.EXE] [[{/run | /r}] | [/runexit] | [{/make | /m}] projectname] [/out filename]
[/outdir path] [/d const=value{[:constN=valueN]}]
[/mdi | /sdi] [{/cmd argument | /c argument}]
/run or /r projectname Tells Visual Basic to compile projectname
and run it, using the arguments stored in the Command Line Arguments
field of the Make tab of the Project Properties dialog box.
/runexit projectname Tells Visual Basic to compile projectname and
run it. Visual Basic will exit when the project returns to design
mode.
/make or /m projectname Tells Visual Basic to compile projectname
and make an executable file from it, using the existing settings
stored in the project file.
/out filename Specifies a file to receive errors when you build
using /m or /runexit. If you do not use /out, command line build
errors are displayed in a message box.
/outdir path Specifies a directory path to place all output files in
when using /make.
/d or /D const=value... Tells Visual Basic which values to use for
conditional compilation constants when making an .EXE or ActiveX
component with the /make switch. Separate multiple constants with
colons.
/cmd or /c argument Puts argument in the Command Line Arguments
field in the Make tab of the Project Properties dialog box. When used,
this must be the last switch on the command line.
/mdi or /sdi Changes the Visual Basic environment to either Single
Document Interface (SDI) or Multiple Document Interface (MDI) mode.
Visual Basic remains in this mode until you change it.
You may use a group name in place of projectname in any of the above
switches.
Sourced from here is some additional information which pertains to older versions of VB as well. That external page may eventually disappear.
VB Command Line Summary
All Versions
vb*[.exe] [[{/run | /r} projectname] {/make | /m } projectname]
{/cmd argument | /c argument}]
projectname The name of your project (.vbp) file.
/run or /r Tells Visual Basic to compile and run projectname using
the arguments stored in the Command Line Arguments field of the Make
tab of the Project Properties dialog box. You can run more than one
project using this command. Replace projectname with
projectgroupname.
/make or /m Tells Visual Basic to compile projectname and make
an executable (.exe) file, using the existing settings of the Path,
EXEName, and Title properties of the APP object. You can compile and
make an executable (.exe) file from more than one project using this
command. Replace of the projectname with projectgroupname.
/cmd or /c Puts argument in the Command Line Arguments field in
the Make tab of the Project Properties dialog box. When used, this
must be the last switch on the command line.
Versions 4 + Only
vb*[.exe] {/d compileconst} [{/makedll | /l} projectname]
/makedll or /l Tells Visual Basic to compile projectname and make
an in-process ActiveX server (.dll) file from it.
/d or /D Tells Visual Basic which values to use for conditional
compilation constants when making an .EXE with the /make switch or an
ActiveX DLL with the /makedll switch.
compileconst The names and values of conditional compilation
constants used in the project file.
Version 5+ Only
vb*[.exe] [{/runexit} projectname][{/m} or {/runexit} projectname /out filename}][{/m}][/sdi] or [/mdi]
/runexit Tells Visual Basic to run projectname. If for any reason
the file is changed in the process of running, all changes are ignored
and no dialog appears on exit to design mode.
filename The name of the file to receive errors when you build an
executable using the /m or /runexit option.
/out Allows you to specify a file to receive errors when you build
using the /m or /runexit option. The first error encountered is
placed in this file with other status information. If you do not use
the /out option, command line build errors are displayed in a message
box. This option is useful if you are building multiple projects.
/? Lists the available Command Line arguments.
/sdi Changes the Visual Basic environment to SDI (Single Document
Interface) mode. Visual Basic remains in SDI mode until you change it.
You can change to MDI mode by using the /mdi argument or by clearing
the SDI Development Environment option in the Advanced tab of the
Options dialog box.
/mdi Opens Visual Basic in MDI (Multiple Document Interface) mode.
Visual Basic remains in MDI mode until you change it. You can change
to SDI mode by using the /sdi argument or by selecting the SDI
Development Environment option in the Advanced tab of the Options
dialog box. MDI mode is the default.
/make /outdir path
Here is the output of vb6.exe /?
I have an NUnit test assembly (a .NET DLL). When I click Run in Visual Studio I want it to launch NUnit and run the tests in this assembly. I can do all of that.
Instead of specifying the full assembly name and path in the command line arguments, does Visual Studio support some sort of macro that expands into that for the Command Line Arguments box? Most other development tools I have used support this, but I cannot find anything in the documentation about this.
I was expecting something like: %assembly_full_path%
The reason I want to do this is so if the assembly name or build location changes, then I don't have to update the command line arguments as well.
This doesn't work as far as I can tell. Macros in the Command Line arguments box do not get expanded. Not even environment variables. Bummer.
A workaround is to create a custom tool. Tools + External Tools, Add. Title = Run tests, Command = nunit.exe, Arguments = $(TargetPath), Initial Directory = $(TargetDir). Tweak as needed. You could assign a keystroke to this new tool command, even F5.
Using VS2005, the only item I need to provide in the Command Line Arguments is the name of the dll. I suspect VS sets the default working directory to the project's output directory, as I've never specified the path and yet the tests always load correctly.