[Bug 50849] Multiple .NET 4.x app installers using WiX v3 'InvokeOutOfProcManagedCustomAction, CAInvokeMethod->Invoke_3 return incorrect result with Wine-Mono (Elgato Stream Deck 4.9.3, Garmin Express 6.13)

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50849

--- Comment #11 from Bruni  ---
(In reply to Zebediah Figura from comment #10)
> I don't particularly expect one, but is there an explanation of how domains
> are supposed to work? Just from skimming, it seems like it's set for the
> thread; why is code on the thread running in a different domain?

--Quote from Microsoft--

[...] Cross-domain calls use the same remote call infrastructure as calls
between two processes or between two machines. As such, the metadata for the
object being referenced must be available to both application domains to allow
the method call to be JIT-compiled properly. If the calling domain does not
have access to the metadata for the object being called, the compilation might
fail with an exception of type FileNotFoundException. For more information, see
Remote Objects. The mechanism for determining how objects can be accessed
across domains is determined by the object. For more information, see
System.MarshalByRefObject.

[...]

An application domain forms an isolation boundary for security, versioning,
reliability, and unloading of managed code. A thread is the operating system
construct used by the common language runtime to execute code. At run time, all
managed code is loaded into an application domain and is run by one or more
managed threads.

There is not a one-to-one correlation between application domains and threads.
Several threads can execute in a single application domain at any given time,
and a particular thread is not confined to a single application domain. That
is, threads are free to cross application domain boundaries; a new thread is
not created for each application domain.

At any given time, every thread executes in an application domain. Zero, one,
or multiple threads might be executing in any given application domain. The
runtime keeps track of which threads are running in which application domains.
You can locate the domain in which a thread is executing at any time by calling
the Thread.GetDomain method.

(Taken from
https://docs.microsoft.com/en-us/dotnet/framework/app-domains/application-do...
)

Below is a simplest testcase to demonstrate how a single-threaded application
can have two AppDomains with such a thread running in both domains.

It's also availabel it ideone: https://ideone.com/kUfOND

Regards.

using System;
using System.Reflection;
using System.Threading;

namespace TestTwoDomainsAndSingeThread
{
    public class Worker : MarshalByRefObject
    {
        public void PrintDomain()
        {
            Console.WriteLine("Object is executing in AppDomain "{0}"",
                AppDomain.CurrentDomain.FriendlyName);
            Console.WriteLine("AppDomain for current thread: " +
Thread.GetDomain().FriendlyName);
        }
    }

public class Program
    {
        static void Main(string[] args)
        {
            // Create an ordinary instance in the current AppDomain
            Worker localWorker = new Worker();
            localWorker.PrintDomain();

// Create a new application domain, create an instance
            // of Worker in the application domain, and execute code
            // there.
            AppDomain ad = AppDomain.CreateDomain("New domain");
            Worker remoteWorker = (Worker)ad.CreateInstanceAndUnwrap(
                typeof(Worker).Assembly.FullName,
                typeof(Worker).FullName);
            remoteWorker.PrintDomain();
            Console.ReadLine();
        }
    }
}