@jkotas Could you please take a look? The arm build CI failure should not be caused by my changes.

The change looks good so far, but I do not see the new method getting called anywhere. Does it actually work?

@jkotas I don't have a Windows box on hand this weekend. I'll confirm it on Monday.

BTW, I saw @stephentoub added a test in corefx repo (dotnet/corefx@7608f24), do we need to add a test in coreclr repo either?

Once this is fixed in core-setup as well and the fix propagates from core-setup to corefx, we need to re-enable the test in the corefx repo, and potentially add more variants of it to exercise the distinct cases. Adding a test to CoreCLR repo for this one is not necessary.

All right. I'll first make sure the Environment.ExitCode bug fixed on Windows so that this PR could be merged. Then I'll work on corefx repo for the test stuffs.

@dotnet-bot test Ubuntu arm Cross Release Build
@dotnet-bot test Ubuntu16.04 arm Cross Debug Build

@jkotas I just tried following code on Windows 7 x64:

using System;
class Program
{
    static int Main(string[] args)
    {
        AppDomain.CurrentDomain.ProcessExit += (sender, e) => {
            Console.WriteLine("Original exit code:" + Environment.ExitCode);
            Environment.ExitCode = 123;
            Console.WriteLine("New exit code:" + Environment.ExitCode);
        };
        return 12;
    }
}

The output is

Original exit code:12
New exit code:123

C:\>echo %errorlevel%
12

So on Windows, %errorlevel% won't be changed after Environment.ExitCode set. I'll investigate this issue later.

The problem is that you are not calling UnloadAppDomain2 in this change anywhere. Changing the UnloadAppDomain to UnloadAppDomain2 in the files you are touching in this change should fix the problem.

Thanks @jkotas .

One thing to confirm: I just noticed that the exitCode variable on Windows is declared as DWORD which is unsigned long. However, wmain returns exitCode as int

Quote from MSDN also said the exitCode is an int instead of unsigned long:

The ExitCode property is a signed 32-bit integer. To prevent the property from returning a negative exit code, you should not use values greater than or equal to 0x80000000.

So I guess I can safely cast exitCode to int as UnloadAppDomain2 needs an int instead of DWORD. Please let me know if there's any risk for doing this. Thanks.

With the new commit, %errorlevel% can be correctly set via Environment.ExitCode:

Example 1:

using System;
class Program
{
    static int Main(string[] args)
    {
        AppDomain.CurrentDomain.ProcessExit += (sender, e) => {
            Console.WriteLine("Original exit code:" + Environment.ExitCode);
            Environment.ExitCode = 123;
            Console.WriteLine("New exit code:" + Environment.ExitCode);
        };
        return 12;
    }
}

The output is

Original exit code:12
New exit code:123

C:\>echo %errorlevel%
123

Example 2:

using System;

namespace hl
{
class Program
{
    static void Main(string[] args)
    {
        Environment.ExitCode = 123;
    }
}
}

The output is

C:\>echo %errorlevel%
123

So the bug should be fixed.

So I guess I can safely cast exitCode to int as UnloadAppDomain2 needs an int instead of DWORD.

Correct.

@jkotas I added a new commit so the bug on Windows should be fixed (see #10967 (comment)). Would you please take a look? Thanks :)

LGTM. Thanks!