I'm using Visual Studio 2005 Express Edition with SP1.
I have a Pre-Link Event which needs to invoke one program and send its output to another.
foo | bar
This command works as expected when invoked from a command line or batch file. The command fails when invoked from the Pre-Link Event (even if the Pre-Link Event invokes a separate batch file containing the command). 'foo' runs and produces output which appears in Visual Studio, but this output is not fed to 'bar', and in fact it appears 'bar' is never invoked at all. Even when the Pre-Link Event invokes CMD or NMAKE which in turn invokes the piped commands, only 'foo' runs.
Is Visual Studio broken and/or is there some arcane ritual I can perform to make this work?
This was answered here for the > operator. I suspect the same thing may be happening with pipes.
Related
I have a Visual Studio 2019 project with a Post-Build-Event, that is calling an EXE file I have written in C#.
Post-Build event:
MyTool.exe "$(TargetPath)"
This EXE file is doing some stuff and then calling another EXE file.
AnotherTool.exe SomeArguments
Problem is, if that second EXE file (AnotherTool.exe) gives an error (on StandardError output) or an exit code != 0, Visual Studio is "seeing" that codes, although the AnotherTool.exe is not called directly from the Post-Build event. The Post-Build just called the MyTool.exe.
I want MyTool.exe to handle that exit codes, so Visual Studio should ignore them. But the build fails, when AnotherTool.exe exits with an error.
Any ideas?
Edit: The "MyTool.exe" is calling the "AnotherTool.exe" using System.Diagnostics.Process. I set RedirectStandardOutput = true and RedirectStandardError = true, and then call the Process with Start() and WaitForExit().
But no matter what that process result is, MyTool.exe is always exiting with Environment.Exit(0) to give a clean exit.
Not an answer, but a Workaround that is working:
I created a batch file, that is calling:
start MyTool.exe %1
With this workaround, the build succeeds without error, and the tool chain is started correctly. I get no more error messages displayed in Visual Studio.
Trade off 1: The "MyTool.exe" is now displayed in a command window while running.
Trade off 2: If "MyTool.exe" fails with exit code != 0, Visual Studio won't notice.
If I remove the "start" from the batch, behaviour is like a direct call of MyTool.exe.
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 wondering if it's possible to tell Visual Studio to print the output of an external build tool as it gets it.
I have an external build tool (JSIL) called from my .csproj file like so:
...
<Target Name="AfterBuild" Condition="$(JSIL) != 'building'">
<Exec Command="JSILc.exe $(SolutionPath)" />
</Target>
...
This works fine--the output goes to the Visual Studio output window. However, it seems that Visual Studio buffers the output of the command until it exits and then prints that output in its entirety all at once.
Since the JSIL compiler takes a relatively long time and has quite a bit of output, I would like for the output window to reflect that while building.
JSIL outputs commands by printing to stdout or stderr, but manually .Flush()ing these streams doesn't seem to affect the output window. Is there some special API that I need to call to update Visual Studio about the progress of a custom build tool?
Thanks!
When I copy/paste the lines below into a cmd window it executes without a problem.
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\vcvars32.bat"
msbuild proj\projsln /p:Configuration=Debug
proj\proj\bin\Debug\proj.exe my args
However when I save it as DoStuff.bat I get the message below (which is the text from executing vcvars32.bat), then nothing else. It does not build my project and obviously doesn't run the newly built executable.
Why doesn't it and how do I have it run all three commands?
>"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\vcvars32.bat"
Setting environment for using Microsoft Visual Studio 2010 x86 tools.
Use CALL to call another batch file.
Well, there has to be a reason it isn't continuing. Is it that the command is waiting for some input? Thats all that I can think of. Try re-directing the output of the batch file to a log and see what is going on.
Alternatively, split the batch file into separate batch files and put a CALL before each call to the batch file.
Is there a way to use the popular Console2 cmd.exe replacement for Visual Studio debugging? In other words, when I debug a console app under VS, I want it to use Console2 instead of cmd.exe.
Interesting question. I looked into it, there are some options but none are pretty.
Console.exe takes arguments, so it's possible to start it with a specific tab and execute an arbitrary process. However, this process will always be run within it's own cmd.exe; for example if your program is c:\my.exe and you launch Console as console.exe -t tabname -r c:\myexe Console2 internally calls CreateProcess( ... cmd.exe c:\my.exe ... ), as a result you can't even see the output of my.exe. This is easily solved though: launch it as console.exe -t tabname -r "/k c:\myexe": the /k switch makes the cmd.exe stay active and you can see your program's standard output. (I looked through the source but couldn't find a way to 'attach' a tab to a currently running Console instance, so launching with arguments will always create a new instance, not sure this is what you are looking for?
You can easily modify the project's debugging properties to reflect the above:
Command: /path/to/console.exe
Command Arguments: -t tabname -r "/k $(TargetPath)"
When starting your exe from within VS, it will launch your exe witin a Console session. However the debugging won't work as VS will try to debug console.exe, not my.exe since that is now a different process. Putting a DebugBreak(); as first line in your exe's main() will sort of solve this, as it will present you the option to debug your exe. All in all, this may a bit too much of a hassle to achieve what you want, but i don't think there's another way: Console always spawns a new process, so the only way to get it debugged is to attach the debugger to it after that process started.
Scott Hanselman blogged about this.
He suggests using this value for Console Settings > tabs > Main > Shell :
%comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"" x86
Sadly for me, This does not appear to work for Visual Studio Express 2010, which lacks a vcvarsall.bat file.