Is there a way to make Visual Studio expand * in file names (and directory names) before invoking the debugger? When I write, e.g., *.txt as the command line arguments, the args[] variable will contain just one entry ("*.txt"), rather than one entry for each matching file. Do I have to write my own code to do this expansion?
If you are invoking visual studio as such:
devenv /debugexe 'myprogram' *.txt
then yes, args[] will contain '*.txt' and you will need to parse and respond to that in your program. (Just the same as if you'd launched the program without the debugger).
Related
I am using visual studio to develop a command line program which takes certain parameters from the command line arguments and its input from the stdin. Currently I am debugging it by setting the parameters manually in project properties as seen in the screenshot:
However I am using a script to generate and compare input, parameters and outputs and I would like to debug the errors, once I have found the appropriate inputs/params/outputs with my script, inside visual studio. Currently I have to manually copy the parameters, I would like to have them read from param.txt which is in the same directory as input.txt which works as an input.
I'm creating PowerShell module in VS 2012. So for comfortable debugging in debug project properties I set Start action to start external program PowerShell.exe and in command line arguments I want to add
-Command { Import-Module [MyDllFileName] }. What should I write instead of [MyDllFileName]? There should be my compiled dll.
The answer propsosed in the linked question is still pretty much valid, but you have to think it through a bit.
First of all the actual answer remains: it's simply not possible to get the assembly name onto the debug command line using the project settings.
Second there are a couple of things you can do however:
The debugger command line is stored in the projectname.vcxproj.user file as the LocalDebuggerCommandArguments property. Write a script/extension/... to set that property to $(TargetPath) and off you go.
Based on the solution propsed in the other question: use an external tool with something like devenv /DebugExe powershell.exe - Command { Import-Module $(TargetPath) }.
Like 2, but place a DebugBreak() statement somwhere in your dll and just launch PowerShell, it will coma and ask to attach the debugger when it sees DebugBreak/add.
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.
I have a solution file for a command line executable. I want to run my executable, with different inputs, through the debugger without my interaction, while also setting its output to a log file.
For example, this is sort of what I want:
devenv /DebugExe "myprogram.exe" "my inputs"
That loads VS and automatically sets my programs inputs. However, I want to do this over and over with different inputs to my program and mine the output files later. So the closest I've figured out, but doesn't work, is this:
devenv /RunExit "myprogram.exe" "my input set" /Out out1.log
devenv /RunExit "myprogram.exe" "a different input set" /Out out2.log
...
Is there any way to do this? Again, the important part is that I could queue up a bunch of runs and mine the output files later for their output.
While I did find a way to do what I want, I don't like it. So I'll wait a while before marking my own answer as accepted.
What I really needed and wanted was what I stated in my question:
devenv /RunExit sln "input args" /Out out.log
The problem is that VS doesn't allow this, "input args" is invalid - unlike if you were to use say /DebugExe but then there is manual work involved again and that didn't help me. So in the script I'm using to call devenv dynamically, I used a regex to replace the "Arguments = " line in the sln file with the appropriate arguments each time. Then this command line works:
devenv /RunExit sln /Out out%x%.log
Each call the sln is modified to contain the new set of args and so each run, I'll get different output in my out%x%.log file (which I name differently each run so I can keep track of which log file went to which inputs). Thanks everybody for watching.
I wanted to do something similar: in my case one of my parameters was a file system path, which could contain a space, which would have to be quoted, inside the string in the batch file which must be quoted. I enhanced my command line executable's code to also look at environment variables (Environment.GetEnvironmentVariable) in addition to the command line parameters to it. Then just set the specific environment variable value prior to each invocation of devenv.
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.