I have two projects running in Visual Studio but whenever I exit one the other keeps running. How can I close both?
Ps: I'm using Application.Exit() to close the first one
If you want to use Application.Exit() to close the first process, and you want to close the second process at the same time, try adding the following lines immediately before you call Application.Exit():
Process[] processes = Process.GetProcessesByName("SecondProcess");
processes[0].Kill();
where SecondProcess is the process name of your second process. (You will also need to add a using reference to System.Diagnostics.)
This code assumes exactly one such process will be running; if that's not necessarily the case, you might need to do more.
Use with caution: killing a running process like this might not be advisable! Other methods are possible and probably better but without more information about your exact setup it's hard to know which approach to suggest.
Related
I want to start vscode as an external editor in a program that Im writing in c#. I use the Process class. I can do that but I also like to be notified when a particular instance is closed. Now I run into problems. If I only start one instance of vscode, the process terminates when that window is closed which is what I want. However, if I start a second vscode that process will terminate immediately. This becomes an issue when the user already has an instance open and use my program.
Anyone with an idea on how this can be solved?
Two parts are necessary to answer your question.
The first is the pure C# one: How to start a process and wait for it to end
Everything you need for this is in the Process class.
To start a process: Process.Start
Once started, to wait for exit, you have a few options:
Process.WaitForExit
Process.WaitForExitAsync
Process.Exited (this is an event handler that you can subscribe to)
Then there is another part needed to answer the question: How VS Code behaves when started from the command line and its options
By default, VS Code will return immediately after starting (so as not to block a shell if it was started from CLI). So, you'll need to pass a few parameters.
Based on the previous link, those would be:
-w or --wait => Wait for the file to be closed before returning.
-n or --new-window => Opens a new session of VS Code instead of restoring the previous session. (this is default behaviour, but you might want to specify it anyways in case this ever changes [or the user changes this])
I've worked on quite a few WPF solutions, and this is the first time i am seeing this problem.
Today it started happening intermittently. where after closing my WPF window, the .exe is still running under visual studio.
so i have to kill my program.exe manually in order to compile again.
Initially i thought because i overrode application start/exit/exception .. but i commented all that out, and it is still happening.
In fact, i see multiple instances of my program.exe in process explorer!
Can't figure out what is causing my exe not to exit. Is there any explicit dipose logic i can add in applicaton exit event to ensure it really exits?
My application consists of single window, and multiple user controls as views.
update
if i open in debug mode. and close the main WPF window, my visual studio does not stop debugging. however call stack window is empty.
You can use the Application.Exit event to log when your application shuts down.
Alternatively, you can attach the debugger to your running instance (even if it wasn't started in the debugger) then pause it to see where it's at. Make sure to look at the Threads tool window, as you may pause outside the UI thread.
This should take care of it, though its probably better to try to figure out the underlying issue.
System.Diagnostics.Process.GetCurrentProcess().Kill();
I have a question. The problem is that I have another process which invoked ShowDialog() method, I need to close this dialog from another process but I need to close it with returning DialogResult.OK.
So from my .net program(another process) I want to close it successfully. I tried to use winapi to solve this problem, tried EndDialog function, but it returns error that ACCESS_DENIED. Tried to use hooks but those return error_no_token.
I need this to start msi installer silently. I start it with /qn switch, but this damn installer has embedded action that shows dialog in any case. I tried to close this window with sendmessage function, but in this case installer says that it is error, and rolls back the install process. I can fill all the values programmatically and click OK button on the dialog, but it requires to fill ALL THE VALUES, and there are lots of them, so it is time consuming. The purpose of this dialog is to create config file, which I can create manually later, after installation.
Is there any way to accomplish this task?
It sounds like the main issue you are having is doing a end-run around the validation for the text fields. As you said you would be editing the configuration files later just put some dummy values in each box and click the OK the way that causes the validation to happen.
Sometimes you need to change a bad design to remove the need to do a hard task, rather then keep fighting the system.
A UI is owned by one process, and apart from automating tests, should only be changed by that process or the user.
There used to be installer toolkits aims at system admins, that would watch the registry and file system while running a installer and then create a custom MSI file to automate the process. This may be another way for you to go.
how can I kill process or close whole application for my WPF application using c#?
Are you using WinForms? Assuming you want to close it via code (and not from the window's close button), you could use Application.Exit. If you want to kill a process, then you can use the Process.Kill method.
Edit - Since you're using WPF, you can use the Application.Shutdown method.
You can Kill a process using Process.Kill, and close it nicely using
Process.CloseMainWindow.
To find the process, use methods of the Process class such as Process.GetProcessById or Process.GetProcessesByName.
However, to kill another process (depending on the process), you may need elevated permissions. You'll need to start your executable with these in order for this to work, in that case.
You can use Environment.Exit to close your own process, or Environment.FailFast to kill it quickly.
Edit:
Since you're using WPF, you can also use Application.Shutdown to close your own application.
Use the Process class.
To avoid crashes, use an outer catch block - sometimes the System.Diagnostics classes cause operating system level exceptions that I usually want to ignore in the case of a small scale utility app.
Is it possible to rise a cmd.exe processes from the silent background mode to the visible foreground so I can LOOK at them?
Problem Background:
I'm using VS2008 working with a very large solution containing C#, C++, and Fortran. Occasionally (a few times a day) when building my project the build hangs and does not allow me to do anything in VS (resulting in the need to kill the process). I have checked the output box, and there appears to be nothing helpful there.
Possible Cause:
I am thinking that maybe one of the cmd.exe windows that are spawned in the background may be waiting for some form of input, but to investigate I need to see those windows.
Search for Other Causes/Solutions:
If not this, is there a way to try to check and see if there is something else going on? Is this a problem anyone else is having. (Note: killing VS and reloading often fixes the problem first try, and the build process takes less than 15 seconds.)
If stopping and restart fixes the problem, I guess it's not an input problem.
For example when my build project halts, it's always the VB6 project or SVN that are upset. (strangely the VS projects always work fine).
Once one of these halt, they halt until they are fixed. Thus for the VB projects run and work-out what the model dialogue is saying and fix it. or on SVN it usually need a clean-up run on the directory.
The intermittent nature suggests some sort of timing issue, like a file been lock open etc.
You could attach another copy of visual studio to the cmd.exe and see where it's at. Not sure if you can get symbols for it, so it might be fun to diagnose.