My post-build event works, but in some situations I am quite sure it is showing an error in the console window. However, because the window closes immediately, I'm not able to read any of it.
This is the build event:
if $(ConfigurationName) == Release start xcopy /y "$(TargetDir)*.dll" "$(ProjectDir)../../bin"
Basically it copies the built dlls over to another directory.
Is there a way to force the console window invoked by start to remain open until I close it?
I think that the information that you want is written in the "Output" (Views > Output or Ctrl-W + O). That information is still written/available after everything has ran.
For example, the output for
echo Information on the post build event
some_non_existant_command
is
Information on the post build event
'some_non_existant_command' is not recognized as an internal or external command, operable program or batch file.
which will give you a better hint at what's going wrong than the Error List (Ctrl-W + E) which will only display something cryptical, like "... exited with code 9009".
So, my advice, check the Output!
Hope it helps.
Related
I'm working on a project where I need a script to execute when someone hits "F5" or "F6", even if the code in the project hasn't changed.
The script is responsible for copying data from a different directory - data that may have changed.
I've noticed that this works properly as a post-build event, but only if the project is actually rebuilt. How do I get the event to trigger without requiring a clean each time?
These are the steps I followed to setup the script to run when I needed it:
Opened Project > Properties
Navigate to Custom Build Step > General
Put the script command in the "Command Line" field
Set an arbitrary output filename (this is required, if you don't have an output filename, visual studio will skip your custom build step) I chose an arbitrary filename ".filename" if I were to get fancy I'd also have the script output a log to this file
Set the "Execute After" field to "FinalizeBuildStatus" This ensures that the command will execute after the build status has been established (which happens in all circumstances when you'd hit F5 or F6, even if you haven't changed any code in the project).
I was surprised not to find these steps clearly outlined elsewhere online. Perhaps I'm bad at googling, but since I solved my own problem I find it only fitting to share in case someone else has this problem.
Using Windows, I entered a command in my cmd window to run an executable file that has your basic "Hello, world!" line printed by the program. When I enter the "start out.exe" command though, a window opens and closes in a quick second. I'm guessing that this window is the window where the hello world message is being printed, but it closes so quickly (maybe because the program is finished). Is there some sort of setting I have that is causing the window to close immediately? Is that just the default? And if so, is there a setting or something that I can change to prevent the window from closing immediately (without changing the nature of the program)? Thanks in advance for your help. I've seen some similar questions, but the ones I have seen are specifically for Linux/Unix or suggested to change the program itself.
If you possess .PDB files, generated at build time (symbols of .EXE file) and required .DLL libraries for your program (In your case those might not be required due to the simple nature of a "Hello World" program), you could try to open the executable as project in Visual Studio and attach a debugger to it, using breakpoints to stop program executions before main returns. This article shows how to do it as a proof of concept.
Open .EXE file by opening VS and navigating to File-Open-Project/Solution and selecting the executable file, then right-click on your "solution" and press Debug-Start new instance. PDB and DLL files should be in the same folder as EXE file.
If you also don't have source code available of the program, follow this advice in order to try to debug it:
To effectively debug you’ll also need the source code that was used to build the EXE, even for just a few files that you care about. You’ll need to locate those files and open them in Visual Studio. If the source code isn’t the exact same as the source code that was built the EXE Visual Studio will warn you when you try to insert a breakpoint and the breakpoint won’t bind. That behavior can be overridden from the Breakpoint Settings peek window. In the settings peek window click on the Must match source link text and then check the box to allow mismatched source, as illustrated below. Of course, with mismatched source you never really know what’s going to happen, so use at your peril.
Disclaimer: I'm not really sure how this method is effective without source files, but I think it's the closest to your answer without changing the actual program.
As another option, you can try invoking your executable file by creating a custom program that invokes the program and redirects its stdout and stderr, like this, for example, or using pipes, check there. The custom program would eventually create a process using as executable your original .exe program and do something with stdout/stderr, for example showing them in your custom program console or saving the output to a file, thus allowing you to read your original program output without the window closing issue (Of course, the original window will still close itself, but I don't think it would matter for you too much).
Or if you want a quick'n'dirty way, you could try to capture the program output by making an invoker Java program. Replace commands array with your program executable name with arguments:
Runtime rt = Runtime.getRuntime();
String[] commands = {"system.exe", "-get t"};
Process proc = rt.exec(commands);
BufferedReader stdInput = new BufferedReader(new
InputStreamReader(proc.getInputStream()));
BufferedReader stdError = new BufferedReader(new
InputStreamReader(proc.getErrorStream()));
// Read the output from the command
System.out.println("Here is the standard output of the command:\n");
String s = null;
while ((s = stdInput.readLine()) != null) {
System.out.println(s);
}
// Read any errors from the attempted command
System.out.println("Here is the standard error of the command (if any):\n");
while ((s = stdError.readLine()) != null) {
System.out.println(s);
}
I hope someone got an idea for a little problem of mine...
I got the following Postbuild-event script in my visual-studio 2010 project:
copy "D:\Sources\Project/output\program.exe" "D:\Project\Testserver\"
cd "D:\Project\Testserver\"
start "" /I "D:\Project\Testserver\program.exe"
The program is starting properly in a new window but the build-process is not ending before I stop the batch.
The same command in a normal windows shell does create a new independent instance but visual studio seems to wait for the process to end, why? I just want it to copy and start the program and then complete the build-process, is there a way to accomplish this? Thanks!
Oh and the follwing error is thrown in the visual studio output window:
Error: The input redirection is not supported. Process will be killed immediately.
(I translated this from german text but still google does not find anything to this error-message)
Would be cool if someone has experience with this. Thanks!
Whenever I call Item.DownloadFile(string localFileName) or VersionControlServer.DownloadFile(string serverPath, string localFileName) I get a FileNotFoundException whenever I try to debug in Visual Studio: Could not find file 'C:[Project Path]\bin\Debug\[ProjectName].vshost.exe.config'.
When I build the application and run it outside of visual studio there is no problem calling these functions. It works perfectly fine. Anyone know what could be causing it?
Before you ask, no, that file does not exist. I'm not doing anything with a config file, I don't need or want it to exist. I don't understand why it is even trying to access that file when I debug. When I run the application outside of visual studio that .config file still does not exist but I get no exception because it's not trying to access that file.
Also, it is not a vshost problem either. When I uncheck "Enable the Visual Studio hosting process" I get the same exception except when debugging but the file name changes from "[ProjectName].vshost.exe.config" to "[ProjectName].config"
Currently, when I want to debug this project I have to put a MessageBox.Show( ) function right after every call to DownloadFile( ) and run my application outside of visual studio. When that MessageBox is displayed then I can use attach to process and put a break point on the next line after that MessageBox, click OK on the messagebox and then it will catch the break point. But when I'm downloading files in a loop and want to debug the loop it's extremely annoying and time consuming to attach to process after DownloadFile is called, stop debugging before the next DownloadFile is called, attach to process again after DownloadFile is called, and keep repeating that all day long.
I'm not totally sure, but looks like it has something to do with the current path and the Workspace where you download the file to.
If you don't explicitly specify the workspace, the TFS API will try to determine it from the current path of your application by looking if that path is declared in a Workspace as a Mapping.
If I remember correctly, you can download an item from a Workspace object (or specify the Workspace in the operation), try to modify your code to do that and see if it's better.
You can also try to change the current path of your debugging session to something "inside a Workspace"
I just wrote a little program which will be executed as a post-build step when I compile certain projects.
This program returns 0 for success, or some number for failure. In case of failure, Visual Studio then correctly outputs: "The command [...] exited with code n."
However, a single number is not always helpful. In my case, I actually want the error to point to a specific place in the source code. Is it possible to output a filename and line number in such a way that Visual Studio will actually let me just double-click on the error and get there instantly?
If the program you're running is a console application, I think its output will appear in the output pane. If the output is of the form
D:\dev\project\Code\MyClasscpp(68) : something terrible happened
then you can double-click on the line and the editor will open on the indicated line.