MVVM Toolkit not correctly unloading using Appdomain.Unload() with Version 7.1

[c-fricke]

Hello!

After updating the version of the Toolkit from 7.0 to 7.1 we cannot unload the Appdomain correctly anymore.
Some background: in our Application we start another Appdomain containing the View that uses the MVVM Toolkit. After closing the View we also unload the Appdomain (via AppDomain.Unload(domain)) to properly unload everything. After updating the Toolkit from 7.0 to 7.1 this unload process runs forever (>10 minutes) and slows/blocks any further code being run in our Application. Going back to Version 7.0 fixes the issue. If you need furthe rInformation regarding this issue please reach out to me, I will help in any way I can.

Best Regards
Chris

Hello c-fricke, thank you for opening an issue with us!

I have automatically added a "needs triage" label to help get things started. Our team will analyze and investigate the issue, and escalate it to the relevant team if possible. Other community members may also look into the issue and provide feedback 🙌

[Sergio0694]

Hi @c-fricke! This seems pretty interesting, could you provide us with a minimal repro to help us investigate this? A small snippet just creating the new app domain and having just enough code to reproduce that hang you mentioned when trying to unload the domanin as you mentioned would be very useful. Thanks! 😊

[c-fricke]

Hello Sergio,
sorry for the delay, sadly had no time over the weekend to create a minimal repo for this.
In the attached Repository you can see an example! When you start the WindowsFormApp and click the Start Appdomain Button it will start the WpfApp which then sends a Message using the WeakReferenceMessenger. Closing the WPF App and then Unloading the Appdomain via the Unload Button leads to the described Error (In our Application this happens automatically if you close the other Appdomain we try unload). If you comment all Code using the MVVM Toolkit in the Wpf App the AppDomain unloads without any problems.
If i can help you any further I would be glad to!
Thanks and have a nice day!
ReposToReproduce.zip

[Sergio0694]

Thank you for the minimal repro! I can reproduce the issue, but I can't reproduce it not happening anymore without the MVVM Toolkit. I've tried both commenting the message broadcast in the WPF app as well as removing the MVVM Toolkit dependency entirely from the WPF app, but if I start the VB.NET app, create the app domani, close the WPF window and then click on "unload domani", the main window still hangs for me. Maybe I'm missing something, but this doesn't seem related to the MVVM Toolkit from what I can see here 🤔

[c-fricke]

Hey,

sorry reading your answer I realized I haven't told you that the WindowsForm App uses the .exe inside its own "/bin/debug" directoy. So in order to see changes you make in the WpfApp you have to either copy the exe and its dlls over there or configure the buildpath of the project (Will update tomorow with a working project file that does this automatically, until then I hope this answer help you further). Will also update it with a Version of a repository where its working so you can see the difference immediatly at that time!

[Sergio0694]

Hi, yeah having a repro project where changes to the WPF app are applied automatically would help a lot! Thanks! 😊

[c-fricke]

Hey,
here a version with a working BuildPath for the WpfApp, if ou compile it in Debug it should now automatically build into the bin/debug of the WindowsFormsApp so you can start the winform app and test immediatly (please recompile before testing to confirm!).
I tried and commeting everything from the MVVM Toolkit immediatly allows the onloading of the appdomain, same with changing the Version to 7.0 with NuGet. I have saved the states for the repos where I did this, if you are interested in them give me a shout and I will also upload those.
Repos_ NotWorking_With_BuildPath.zip
,

[Sergio0694]

So I've investigated this more and managed to find a minimal repro for the issue:

public sealed class WeakReferenceMessenger
{
    public WeakReferenceMessenger()
    {
        static void Gen2GcCallbackProxy(object target)
        {
        }

        _ = new Gen2GcCallback(Gen2GcCallbackProxy, this);
    }

    // Commenting out this field fixes the issue
    public static WeakReferenceMessenger Default { get; } = new();
}

public sealed class Gen2GcCallback : CriticalFinalizerObject
{
    private readonly Action<object> callback;
    private GCHandle handle;

    public Gen2GcCallback(Action<object> callback, object target)
    {
        this.callback = callback;
        this.handle = GCHandle.Alloc(target, GCHandleType.Weak);
    }

    ~Gen2GcCallback()
    {
        if (this.handle.Target is object target)
        {
            this.callback(target);

            GC.ReRegisterForFinalize(this);
        }
        else
        {
            handle.Free();
        }
    }
}

It seems the combination of the GC callback with that static field is causing the whole thing to remain rooted on .NET Framework (works just fine on .NET Core), so the app domain cannot be unloaded. Commenting out either the static field or the GC callback solves the issue. Not entirely sure how to fix this from the MVVM Toolkit though... 🤔

EDIT: at least for now, I've just disabled the auto-trimming on .NET Framework. Does the trick, we should document it.

[Sergio0694]

This was closed by e2b3361, will be available in a future release 😊