Await Task hangs if creating a new form instance before running the task

Question

My await code hangs if I run a create a new form instance before running the await code.

If I comment the line Form frm = new Form(); the code will be run properly otherwise it will hang in the code await Task.Delay(2000);.

Another solution is to create a new form instance using Task.Run(the commented line in my example code). I have no idea why it does work and doesn't know if that's fine to create a new form instance in a subthread.

Here is a simple example code to replicate the problem. Is there anyone have the idea why does this happen?

using System.Linq;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
using System.Windows.Forms;

namespace ConsoleApp1
{
    class Program
    {
        public async static Task Main(string[] args)
        {
            //Form frm = await Task.Run( () => new Form());
            Form frm = new Form();
            await Delay();         
        }

        public static async Task Delay()
        {
            await Task.Delay(2000);
        }
    }
}

Sorry for the confusion. Added the real code I am writing which is actually the unit test code.

    public async Task TestFrmLoginGen1()
    {
        IFrmLogin frmLogin;
        frmLogin = await Task.Run(() => new FrmLogin());
        //frmLogin = new FrmLogin();

        FrmLoginPresenter loginPresenter = new FrmLoginPresenter(frmLogin);
        await  loginPresenter.LoginAsync();
    }

Answer 1

The other answers saying that you shouldn't be creating forms inside a console app or a unit test are absolutely correct.

From your updated code, it looks like someone has already gone to the trouble of making sure you can unit-test your presenter without having to instantiate your form: the FrmLoginPresenter constructor takes an IFrmLogin, which I'm assuming is an interface implemented by FrmLogin. This abstraction exists to allow you to unit-test FrmLoginPresenter without having to create an actual FrmLogin.

What you want to do is to create a mock implementation of IFrmLogin. This might be a normal class which you write yourself which implements IFrmLogin (it might already exist in your test suite), or it might use a mocking library like Moq or Rhino Mocks.

Then you pass your mock implementation to the FrmLoginPresenter constructor.

Ultimately, it looks like whoever architected your application has already thought about how it should be unit-tested. You should probably go and speak to them to get the full picture on their intentions.

Answer 2

Your code is never calling Application.Run() to start the message loop of the application.

When you use await, the continuation may be posted to the message loop depending on the context. Once you create a form, you are in such a context and you have to make sure that the message loop actually runs.

The bit of initialization code of a WinForms application where Application.Run() is normally called is not a good place to use async/await.

Answer 3

My await code hangs if I run a create a new form instance before running the await code.

Well there are a number of reasons for that.

1. Your app is actually a console app and not a WinForms app. You are attempting to show a GUI in a console app which typically isn't possible

2. Console apps default to a MTA rather than STA. STA is required for all apps running a GUI

3. Console apps don't process the Windows Message Pump unlike say native windows or a WinForms app

Sure you can add a message pump to a console app; force a STA thread but why would you when there is a perfectly good WinForms wizard in Visual Studio?

I comment the line Form frm = new Form(); the code will be run properly

I really doubt that. You might have a window appear but it certainly won't be interactive. Unless the message pump is processed the window won't paint (including painting after a window, that was in front of it, is moved away). Clicking buttons and menus will be unresponsive. Timers will be inoperative.

Finally, don't attempt to create a GUI via a thread and/or Task as you will have little control over STA. It all must be done from the application's primary thread which must be STA as mentioned. There is little reason for multiple STAs.

In conclusion there is little point for using async/await during construction of a window.

Answer 4

I'm a bit late to the party, but I found myself running into the same problem (Although my use case was an app that can be run as a windowless process or a GUI). I'm going to leave my solution for the next poor soul who wanders here.

Doing HTTP Async operations seem to be a big culprit (Task.Delay didn't cause deadlocks/hangs for me). The following triggered the same behaviour as OP

static async Task Main()
{
    Application.EnableVisualStyles();
    Application.SetCompatibleTextRenderingDefault(false);
    var fooForm = new Form1();
    fooForm.RunLoginTest().Wait();
    Application.Run(new Form1());
}
public async Task RunLoginTest() {
    var tokenClient = new TokenClient("https://dev1idsrv.biz/connect/" + "token", "----", "----");
    var tokenResponse = await tokenClient.RequestClientCredentialsAsync("cloud_api_gateway");
}

As stated by others, running async code before Application.Run causes issues. The next attempt was triggering the async code inside the Application.Run() by sticking it inside the constructor method.

public Form1()
{
    InitializeComponent();
    RunLoginTest().Wait();
}

As you'd expect the above also failed, evidently the form actually has to be created before Application.Run does its magic.

Accordingly, sticking the code in the form_load event was what ended up working

private async void MyForm_Load(object sender, EventArgs e)
{
    this.Opacity = 0; //to hide the form
    this.ShowInTaskbar = false; //to hide the form
    await MyAsyncMethod();                
    Application.Exit();//or Form.Close() or neither, depending on your use case
}

For my use case I wanted the code to run but not have the form show up. Any attempt to set .visible gets overriden, so instead I've set it invisible through other methods. The above code block successfully runs the async code without triggering deadlocks