Reliable way to check if current thread is the main thread in console and WPF applications

[alexey-leonovich]

I need to check if current thread is the main thread. I need to support both console and WPF applications - so I cannot check SynchronizationContext.Current or Application.Current.Dispatcher.Thread. An I need to support both .NFW 472 and .NET 8.0.

1. Is it reliable to suppose that for a main thread Thread.CurrentThread.ManagedThreadId always equals 1?
2. If not - is it enough to check via

if (Thread.CurrentThread.GetApartmentState() == ApartmentState.STA && Thread.CurrentThread.ManagedThreadId == 1 &&
    !Thread.CurrentThread.IsBackground && !Thread.CurrentThread.IsThreadPoolThread && Thread.CurrentThread.IsAlive)
{
    // it is the main thread
}

or is it an overkill and there is a simplier solution?
3) Or maybe some extra checks via reflection are needed:

public static bool CheckForMainThread()
{
    if (Thread.CurrentThread.GetApartmentState() == ApartmentState.STA && Thread.CurrentThread.ManagedThreadId == 1 &&
        !Thread.CurrentThread.IsBackground && !Thread.CurrentThread.IsThreadPoolThread && Thread.CurrentThread.IsAlive)
    {
        MethodInfo correctEntryMethod = Assembly.GetEntryAssembly().EntryPoint;
        StackTrace trace = new StackTrace();
        StackFrame[] frames = trace.GetFrames();
        for (int i = frames.Length - 1; i >= 0; i--)
        {
            MethodBase method = frames[i].GetMethod();
            if (correctEntryMethod == method)
            {
                return true;
            }
        }
    }
    return false;
}

Thank you.

[jkotas]

What do you need this check for? In other words, what is your definition of main thread? For example, what's the main thread if the .exe is native binary and the .NET runtime is used to run a COM component?

Neither of the code snippets that you have shared above look reliable.

The fully reliable way would be to have the caller of your code to set the main thread explicitly.

[alexey-leonovich]

I need to support UI (WPF, WinForms, Avalonia) and console applications targeting both .NFW 472 and .NET8.0+. Inside them I need to catch exceptions that occur in not-main threads (in operations started with Task.Run()) and rethrow them to main thread.
Now I'm using a common approach with capturing main thread context with:

static void CaptureMainContext()
{
    if (_mainThreadContext == null)
    {
        if (SynchronizationContext.Current == null)
            SynchronizationContext.SetSynchronizationContext(new SynchronizationContext());
        _mainThreadContext = SynchronizationContext.Current;
    }
}

and adding a continuation to all operations started with Task.Run() for rethrowing exception to main thread:

public static void RethrowExceptionToMainThread(Task task)
{
    task.ContinueWith(
        tsk =>
        {
            var exceptionDispatchInfo = ExceptionDispatchInfo.Capture(tsk.Exception.InnerException);
            _mainThreadContext.Post(ex => (ex as ExceptionDispatchInfo)?.Throw(), exceptionDispatchInfo);
        }, TaskContinuationOptions.OnlyOnFaulted);
}

So I need to ensure that CaptureMainContext() is always called on main thread. Handy way to archieve that would be calling inside IHostApplicationLifetime ApplicationStarted event but that approach is only for an application on .NET Generic Host (host.Start() should be called). So I ended up with this question (howto ensure that current thread is the main thread).
Is there a better way to achieve my goal?

[jkotas]

Are you designing a reusable library? Why does the library need to post the exceptions to the main thread?

Reusable libraries typically depend on the synchronization context created by the caller. It is an anti-pattern for reusable library to set the synchronization context.

[MichalPetryka]

I agree that main thread is probably not the thing you really want here. Any UI framework can very much so not be running on the main thread of the app that started with the entrypoint, in fact such thread might not even ever executed any managed code at all in cases of custom runtime hosting.

What you really want here is to get the thread used by the UI framework and as such, it should be them that provide an API for retrieving it.