OMG!
when run projects in vs they just show up and disappear instantly
all of project's are c# console app and i ran them before and that was okay
i've try to reset all setting and that didnt work
If you want your console app to whait for input you can put that at the end of your main method
Console.ReadLine();
Then you need to hit enter to exit the console app.
Another possibility while debugging would be to add a breakpoint at the end of your main method.
It was set to something wrong.
Project start up was set to single project, not current project.
Related
i have a solution
it has 2 projects inside.
there are an exe and a website.
the issue occurred when clicking F5 to start the debug process.
when i have set the exe to the default StartUp project. The exe can run normally, and the break point can be reached correctly.
however, when i have set the website to the defualt StartUp project. The website can be launched, however the breakpoint cannot reach. also the version isn't the latest one, it looks like it is loading the last succeed version (no error and warning too)
I have to right click the website project and click start new instance in the Debug every time I have modified something!(which is very troublesome)
Thus, I want to know why my F5 isn't equal to the Start new instance, as it is working normally in the other solutions.
I fixed that but the below procedures after struggled from extra many clicks compiling experience.
the cause is that there is unknown reason that the build checkbox isn't checked in the configuration manager. simply check it and everything looks fine again...
hopefully it can save someone time who suffered from this issue in the future
I have two console application projects in a single solution and they are both configured to build to a common directory. The first app calls the second app via
Process proc = new Process();
proc.StartInfo.FileName = "myprocess.exe";
I can change my startup project and debug either one of them individually just fine, but I'm unable to step into the second project from the first project. When I look in build\debug I see the .pdb files for both apps and I know the second app is running completely through its routines. I just can't step into it. I've looked at Attach to Process and Debug:Location but haven't been able to find a solution yet. I've even tried putting them in different VS solutions, but to no avail.
So I need a way to step from the first project into the second project while debugging. Any suggestions would be appreciated.
Thank you.
You can use
Debugger.Launch();
which will bring up the dialog asking if you want to attach a debugger. You won't be able to 'step in' from the existing debugging session since it's attached to a different process.
When running a console application in Visual Studio via "Start without Debugging" (Ctrl+F5), the console remains open at the end of the run asking to
Press any key to continue . . .
thus requiring to activate the window and hit a key. Sometimes this is not appropriate.
Why this matters:
At the very moment I write json serialisation code, my workflow goes like this:
adapt c# code
run a console app that writes file out.json
view out.json in the browser with a json viewer
do this again and again, no need to debug anything, just trimming serialisation and check output is good.
It is workflows like this, where the "press any ..." behavior is hindering as it requires the steps
activate the console window
press key
.
No answers:
Starting the application outside VS in a separate console is not an answer.
Saying, you dont need this.
I'm pretty sure that you cannot affect or change this behavior.
As you mention, it has nothing to do with your application itself, because it doesn't do it when you double-click on the EXE. You only see this effect when you run the app from within Visual Studio without the debugger attached.
Presumably, when you invoke Ctrl+F5, Visual Studio is running your app in a particular way that causes the console window to remain open. I can think of two ways it might be doing it:
%COMSPEC% /k "C:\Path\To\YourApplication.exe"
or
%COMSPEC% /c ""C:\Path\To\YourApplication.exe" & pause"
With either of these, the pausing behavior you're seeing is baked right into the command used to launch your app and is therefore external to your application. So unless you have access to the Visual Studio sources, you're not going to change it. Calling an exit function from your app won't have any effect because your app has already quit by the time that message appears.
Of course, I can't see why it really matters, aside from an issue of curiosity. This doesn't happen when you start the app with the debugger attached, which is what you'll be doing 99% of the time when you launch the app from the IDE. And since you don't ship Visual Studio along with your app, your users are going to be starting the app outside of VS.
In response to the updates made to your question, the best solution would be to change your app so that it is not a console application. This behavior doesn't affect standard Windows applications; when they get closed, they close for good.
If you do not require any output on the console window, then this is very simple to do: just change the "Application type" in your project's properties. A Windows Forms application will work just fine. If you do not display a window (aka form), one will not be automatically created. This is the difference between regular Windows applications and console applications, which always create a console window, whether you need one or not.
If you do need to display output on the console window, you have a couple of options:
Create and use a simple form with a ListBox or ListView control. Each line that you would normally output to the console, you add as a new item to the list control. This works well if you're not using any "advanced" features of the console.
P/Invoke and call the AllocConsole function to create a console that your Windows application can use. You do not need a form for this.
I found a solution that works if you are using python (I could not test anything else).
You need to go to
Tools -> Options -> Python Tools -> Debugging
Uncheck Wait for input when process exits normally.
I hope you can apply this somehow to your problem.
2020 UPDATE : Microsoft has listened.
It also closes the console in "Start Without Debugging" mode ;)
The setting is a little buried, but works :
Well, at least in Visual Studio 2010, typing
Console.ReadKey(true);
Removes the "Press any key to continue....."
According to the VS2019 documentation:
Automatically close the console when debugging stops: Tells Visual Studio to close the console at the end of a debugging session.
It works, but only if you make sure your project starts with the debugger on. This sounds trivial, but I was trying at first with a solution with two projects, one Console one to copy files to use in my app, the other to run the actual app. I set the Console one to Start without debugging because I don't need debugging on it, but that did not close it after it ran. Only when setting it to Start (with debugging) this option worked.
In vs2017 you have to uncheck the python environment setting under the vs-options:
in german: Auf Eingabe warten, wenn der Prozess normal beendet wird
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 get the infamous "Dialogs must be user-initiated" Security Exception when I try to print some stuff in Silverlight. As you can see, the dialog is as user-initiated as can be:
John Papa couldn't help me much out neither, because I don't have any breakpoint set. Mr MSDN thinks it could also be that I'm just taking too long, but this is a demo application just as simple as can be.
Any ideas? I guess it's a Visual Studio quirk, maybe some extensions interfering, as things seems to work when I launch the application outside of it. I first thought maybe the Code Contracts are interfering with their IL weaving, but they are deactivated for this project.
Update: This is just a simple Silverlight application that runs locally from the file system. When I do "Start debugging", Visual Studio creates a hosting HTML file containing the Silverlight app in the Debug resp. Release folder of the project, launches the Internet Explorer with that HTML file and attaches the debugger to it.
Update 2: I also get the same error when I create a web project to host the Silverlight app and create a virtual directory for it on IIS.
I might also want to add that I don't have problems with printing in other Silverlight projects regardless of their hosting scenarios.
Update 3: I downloaded FireFox and it works, I don't get the error when I debug with it. So it seems to have to do with my IE8. I uploaded the solution:
http://dl.dropbox.com/u/10401470/Code/Demos/PrintingDemo.zip
I wonder if anyone can reproduce?
Anyone got an idea to which team I should file a bug report? Silverlight team? IE team? VS Debugger team?
I'm able to reproduce this. You have handled the Click twice, once in XAML another time in code. See your MainPage.xaml
<Button x:Name="PrintButton"
Content="Gotta print 'em!" Margin="8"
Click="PrintButton_Click" />
Don't feel bad about it. I did it last time through a misplaced Print inside a loop.
I've also experienced this strange behaviour. A standard button click event immediately invoking an OpenFileDialog. It would frequently generate the same error when being debugged but would eventually be coaxed in to working when the button is clicked several times.
However when built as a release (or perhaps simply by running the same Xap without a debugger attached to the browser) the problem would go away.
Try to remove
if(SightPaleceListBox.Items.Count > 0)
I had the same problem and found out that the reason was this following line:
cnvsMain.Children.Remove(PrintPagePlaceHolder);
cnvMain is on the page that the user pushed the Print button on (I was trying to remove it from that page in order to add it to the canvas that I was going to print).
My tip: try to comment rows one by one, until you find what row causes the problem. Than try to work around it.