I don't think we can change the signature of the existing hosting API. There are other Microsoft projects like dotnet cli and possibly also community projects using the current APIs and this would break them. It seems that we need to create a new version of coreclr_shutdown with the added latchedExitCode and keep the old one unchanged. Named e.g. coreclr_shutdown_2.

@janvorli Should I do the same change on ICLRRuntimeHost::UnloadAppDomain (keep the old one, add a new ICLRRuntimeHost::UnloadAppDomain2)? I found somewhere out of unixinterface.cpp calling this method as well so I have to add a default value to pLatchedExitCode. If this interface is used by other projects we probably have to keep the old signature.

Right, you cannot modify the ICLRRuntimeHost methods either. This is a COM interface and by COM rules, you need to add a new version of the whole interface, called ICLRRuntimeHost4 (there already is ICLRRuntimeHost3) and put the new method on it.

@janvorli I went through the code from coreclr initialization to shutdown. It seems like we need more efforts to address this issue. Therefore I just write down the design here before diving to the code. Please correct me if anything is incorrect.

Current process of executing a managed assembly:

1. In ExecuteManagedAssembly, coreclr_initialize is called to initialize the hostHandle.
2. in coreclr_initialize , a CorHost2 object created, who implemented interface ICLRRuntimeHost2, and a pointer to ICLRRuntimeHost2 is assigned to hostHandle.
3. In ExecuteManagedAssembly, coreclr_execute_assembly is called with hostHandle passed in.
4. In coreclr_execute_assembly, hostHandle is cast to ICLRRuntimeHost2.
5. In ExecuteManagedAssembly, coreclr_shutdown is called with hostHandle passed in.
6. In coreclr_shutdown, hostHandle is cast to ICLRRuntimeHost2.

To fix the Environment.ExitCode issue while keeping ICLRRuntimeHost2 not being changed, I'm going to:

1. Create a new COM interface ICLRRuntimeHost4 which introduces a new UnloadAppDomain method with latchedExitCode as its last parameter.
2. Create a CorHost4 class which implements ICLRRuntimeHost4.
3. Create coreclr_initialize_2, coreclr_execute_assembly_2 and coreclr_shutdown_2 functions. They have same logic as coreclr_initialize, coreclr_execute_assembly and coreclr_shutdown but use CorHost4 and ICLRRuntimeHost4 instead.

You should not need to create CorHost4 . The new interface can be implemented by CorHost2 just fine. Also, you should not need to create coreclr_initialize_2 or coreclr_execute_assembly_2. coreclr_shutdown_2 is the only one needed.

Instead of this query interface here, could you please change all references in this file from ICLRRuntimeHost2 to ICLRRuntimeHost4?

Sure, I've changed them.

Is this really needed?

It will incorrectly overwrite latched exit code for non-void returning functions.

https://github.com/mazong1123/coreclr/blob/0c46640307dab1d8359f4e3b856a4390d9a6389d/src/vm/assembly.cpp#L1854 should take care of it for non-void returning main.

The condition in following line will be false so that L1854 won't be executed at least for this example :
https://github.com/mazong1123/coreclr/blob/0c46640307dab1d8359f4e3b856a4390d9a6389d/src/vm/assembly.cpp#L1852

I don't know why we're checking the stringArgs here so I have to sync the latched exit code outside. Seems like we should remove the check. Do you have any idea about this line of code?

Seems like we should remove the check

Agree.

Could you please also verify that the following program will have exit code 123?

using System;

class My {
    static void Main() {
        Environment.ExitCode = 123;
    }
}

I just ran the sample program and echo $? gave me 123. Note I've removed the check and my sync code before testing. So it works.