I have just begun to explore the mono winforms environment and I cannot work out how to start a program from within monodevelop without a console session being started.
My simple program runs okay but when it exits a terminal session is always created & waiting for me to 'press any key'. I guess I could arrange things so that the terminal window closes automatically, but I would rather the app just ran 'natively', is this possible or does the way mono & .net function work preclude it?
As shown in the examples at Zetcode, in 'Main' the rest of the code is started with 'application.run(new aFunction());', I thought this might be the cause of the terminal session occurring but replacing it with:
myNewClass n = new myNewClass();
n.aFunction();
causes the program to not run at all (or maybe just exit without doing anything).
I am an experienced programmer but not familiar at all with C# or the mono/.net environment so 'stating the obvious' may be all that is required in an answer.
MonoDevelop will usually let you start a program with or without it running in an external console.
In MonoDevelop 2.8 on Linux you can control this by context clicking on a project in the solution tree and selecting Options; then Run on external console under the Run section. I'm not sure if you can disable this on OSX.
Related
I have the simplest C# console app that only does a WriteLine and a ReadLine. For some reason, it doesn't run in standalone mode on the machine it was built. I tried the built executable on another box and it works fine.
Trying to run it on this machine makes it just hang there. It works fine inside VS, just not from the command line.
Trying to attach VS to the hanging process says something along the lines of "ConsoleApplication1 has triggered a breakpoint" but can't see what the problem is (it indicates the breakpoint is _LdrpDoDebuggerBreak#0() in ntdll.dll).
Any ideas on how to diagnose what's going on?
EDIT (answering comments below): Same behavior happens for both Release and Debug. Platform is set to Auto. Both machines tested on are 64-bit. The one it's working on is Windows 7, the one I'm building on (and where it hangs) is Windows 10.
EDIT2: Something else I noticed is that trying to run the app doesn't bring up a console window (so it hangs before that). Also, detaching after attaching to the hanging process also hangs VS.
EDIT3: Here's the full zipped project: (removed). It contains the debug .exe file as well for the curious. It's just a vanilla console application project with the following code:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("ASD");
Console.ReadLine();
}
}
}
Are you sure that there's nothing in your code except a WriteLine() and a ReadLine()? I haven't tested it, but this sounds like exactly the behavior I would expect from calling Debugger.Break().
The MSDN page has a note:
Starting with .NET Framework 4, the runtime no longer exercises tight control of launching the debugger for the Break method, but instead reports an error to the Windows Error Reporting (WER) subsystem. WER provides many settings to customize the problem reporting experience, so a lot of factors will influence the way WER responds to an error such as operating system version, process, session, user, machine and domain. If you're having unexpected results when calling the Break method, check the WER settings on your machine. For more information on how to customize WER, see WER Settings. If you want to ensure the debugger is launched regardless of the WER settings, be sure to call the Launch method instead.
On the machine where it is working, it's either ignoring this line because you don't have development tools installed, or your settings are such that it just skips it. On the machine you're developing on, the settings would be different. Possibly fees are based on the Windows 7 and 10 defaults, but I don't know.
Finally figured it out. It's my lovely antivirus. Hoping this helps someone in the future, Avast doesn't bring up the usual prompt indicating it's scanning the app or quarantining it or anything. Disabling the shields (Avast Shields Control -> Disable for 10 mins) makes the app work properly. Argh!
Thank you all for the support!
Interestingly the other machine where it works is still running Avast, but I think it's one major version behind. This is for version 10.4.2233.
I'm writing an embedded powershell host in C# using VS13 (Windows Application NOT console app). I can invoke powershell commands just fine. The issue I'm having is that when the invoke function handles a console command like ping, netstat, etc. it triggers an instance of conhost.exe to be created. This is normal behavior for Windows 7 and above from my research so far, but when conhost starts up, it briefly flashes a console on the screen.
Is there a way to have conhost start-up without flashing the console window initially? Keep in mind that I'm handling user input into the powershell pipeline so testing for each command, and starting a new process is probably not practical.
It's been a while since I asked this question so I wanted to share the answer I came up with. Basically, since my embedded host was in an application that runs solely in the background, there was no way to prevent conhost from flashing on the screen when "native commands" were processed. It's just the way Windows works. If my host was attached to a GUI then I think there might have been a way to redirect output, but so far for my use case I couldn't suppress conhost.
I have a C# application which makes use of the Microsoft Windows API Code Pack - in particular the Shell Extensions, which I use to monitor storage devices and media insertion and removal.
However when I attempt to close the app in Visual C# 2010 (Express) I then have to manually stop the debugger. It appears that there is a background loop in the Win API Code Pack that is still running, even when I manually dispose of the ShellObjectWatcher. The only way I can kill it is to manually stop the debugger.
The app is built in WPF.
Eventually, VisC#2010 gives up on trying to run the app under the debugger. You tell it to start debugging and it just doesn't. Only way to get it going again is to kill the app using Task Manager and then shutdown VC#2010 - go have a coffee - then start it up again. Odd. I suspect there is a hidden process or window hanging around which isn't being shut down when I try and clean up the app.
Any idea how I can clean up this ShellObjectWatcher a little more effectively?
To fix the bug in the Code Pack Shell project, add one line in MessageListener.WndProc():
case (uint)WindowMessage.Destroy:
**_running = false;**
break;
Now ThreadMethod() will exit the message loop.
OK using System.Environment.Exit(0); fixes this issue. App shuts down and the debugger releases control. Brute force works in this case.
I bumped into the same issue, but solved it by setting the thread as a background thread (meaning, it is killed when the application stops):
in MessageListener.cs, in the constructor, at line 40, I have:
_windowThread = new Thread(ThreadMethod);
// The line below will force the thread to terminate when the app exits.
_windowThread.IsBackground = true;
_windowThread.SetApartmentState(ApartmentState.STA);
My target is to send keyboard events to external application.
From my application, I'm launching a C# exe (console application) that bring the target application to the front and uses SendKeys.SendWait to send keyboards events. I ran into a rate case were the command don't have any affect.
When debugging it, it works but when running it not in debug it fails.
I think it as something to do with the fact that when debugging my application is the active application.
You'll need to do a little work, and it changes depending on the version of Windows. There's an MSDN page that has a good explanation and an example:
http://msdn.microsoft.com/en-us/library/ms171548.aspx
I have a WPF application that occasionally crashes, and say "not responding". Is there a way to detect if the program is not responding? And if so, restart the WPF application?
This will be a temporary fix until the bugs are fixed.
You could use the Application Recovery & Restart Manager API, which was introduced in Windows Vista. This is an unmanaged (C) API, however there are managed wrappers available in the Windows API Code Pack.
This is a good feature to add to your application anyway, as it provides the user with a nicer experience if (when!) you application crashes. You can even write a callback that persists information about what the user was doing, and then restore that state when the application restarts.
The most basic use of the API would be to just add the following line somewhere in application startup:
ApplicationRestartRecoveryManager.RegisterForApplicationRestart( new RestartSettings( "restart", RestartRestrictions.None ) );
Because this is a temporary fix while you debug the app, one possibility is to cheat and use a bootstrapper/startup app whose sole job is to monitor the problematic app. Start the problematic application via the System.Diagnostics.Process class's Start method, then occasionally monitor the returned Process' Responding property. If not responding, do what you need to do.
It's important that this only be done as a stopgap while you fix the real problem, of course. There are lots of little issues with doing something like this long-term.