[Prism] Background activation should not recreate container

[bartlannoeye]

For Bugs:

Repro steps

Repro steps on clean project:

• Add at least 2 pages
• Add background task
• Trigger background task through VS
• Navigate

Expected Behavior

Navigation is succesful.

Actual Behavior

While testing #2621 (on a private repo) I received following exception on first navigation after the event got fired.

Microsoft.Practices.Unity.ResolutionFailedException: 'Resolution of the dependency failed, type = "XXX.ViewModels.YYYViewModel", name = "(none)".
Exception occurred while: while resolving.
Exception is: InvalidOperationException - The current type, Prism.Windows.Navigation.INavigationService, is an interface and cannot be constructed. Are you missing a type mapping?

System

• VS Version: 15.8.5
• WTS Wizard Version: 2.4.18260.1
• WTS Template Version: 2.4.18260.1
• Windows Build:

[bartlannoeye]

Since the background task is in-process, we have a running/suspended application with the IoC container already configured. A background activation in the app should not recreate the IoC container. If I overlook anything, please let me know.

Until the next release, anyone using Background Task and Prism can manually change following code in App.xaml.cs

    protected override void OnBackgroundActivated(BackgroundActivatedEventArgs args)
    {
        base.OnBackgroundActivated(args);
        CreateAndConfigureContainer();
        Container.Resolve<IBackgroundTaskService>().Start(args.TaskInstance);
    }

and remove the CreateAndConfigureContainer(); method, which results in

Edit: there's an edge case where the in-process background task's activation trigger isn't handled anymore before the app is shut down. This will cause a NullReferenceException in the OnSuspending method for the short activation/suspension that's needed to handle the trigger. It isn't a complete fix, but at least your code will be executed now as the exception only happens during suspension so after your logic executed.

The current 6.3 release however closed off all possible paths to circumvent this error and the team doesn't have the right SKDs anymore to create a new manual build (automated builds were added after 6.3). Since we're progressing on a v7 release for UWP, we decided to put our effort there and fix this edge case bug in the next release.

To fix the initially mentioned issue, put a check around the creation of the container, which correctly handles all activations when the application is running or suspended.

    protected override void OnBackgroundActivated(BackgroundActivatedEventArgs args)
    {
        base.OnBackgroundActivated(args);
        if (Container == null)
        {
            CreateAndConfigureContainer();
        }
        Container.Resolve<IBackgroundTaskService>().Start(args.TaskInstance);
    }

[mjmeans]

I spoke too soon. After leaving development for several hours, I started development again and upon first run, App.OnBackgroundActivated() is being called before App.ConfigureContainer(). So simple removal of the call to CreateAndConfigureContainer() corrects the navigation issue but introduces a new activation error. I think this is because the already registered background task has missed it scheduled run time, so it starts first.

[bartlannoeye]

@crutkas can someone responsible for application lifecycle and background tasks contact me? Something in my reasoning seems to be off.

[bartlannoeye]

Adding a check around the container makes sure everything runs on all activations. There's still an issue on suspending (see my updated comment above), but this is the best we can do for now without falling back to Reflection or put more time in finding old SDKs. Our focus is on releasing v7 for UWP asap to fix this issue as well as other open work. But at least your logic will be executed correctly as the error only happens on suspending.

[mjmeans]

Adding what check? Are you referring to a "try/catch" block? If so, then have you confirmed that the internals of CreateAndConfigureContainer don't change any underlying static or singleton classes references in the container system prior to throwing the exception? i.e. Are you sure that just ignoring the error won't contribute to later failures in the container implementation?

[bartlannoeye]

@mjmeans please scroll up to my 1st comment in the thread. I've added a == null check, only when null, we should call the CreateAndConfigureContainer method.

[mjmeans]

Thanks. I missed the Edit.