Blazor and AsyncExecutionFlowScopeContext

[oruchreis]

Hi,
I'm trying to use DryIoc in Blazor apps in our framework. Normally, applications within the framework(Mvc Core, CoreWcf, Console, etc..) use AsyncExecutionFlowScopeContext and employ the OpenScope method in places where async/await is used, enabling them to utilise this scope even in deeper methods. We have lots of methods working like this. When using AsyncExecutionFlowScopeContext with Blazor, it throws a lot of error like RemoteNavigationManager not initalized ,etc.. So I can't use AsyncExecutionFlowScopeContext with Blazor.
What I actually need is to run the OpenScope method with an async execution flow when appropriate and with a thread execution flow when appropriate. That way, I won't have to provide an AsyncExecutionFlowScopeContext when creating the container, and I'll be able to use either async or thread execution flow depending on the situation wherever I use OpenScope. Is there a way to do this? Or what other approach would you suggest?
By the way, I know that async flow doesn't work properly in Blazor, but I need to resolve many points, such as background tasks, with IOC, and this type of usage is found throughout our framework code. Therefore, it is essential that I can run OpenScope with async execution flow.

[dadhi]

How would you envision the API for opening scope in different contexts? Just as a small code example of what you talking about in description.

[oruchreis]

I'm opening scope with these helper methods:

   private IContainer _container = new Container(
            Rules
                .MicrosoftDependencyInjectionRules                
                .WithCaptureContainerDisposeStackTrace()
                , useAsyncLocalScopedContext ? AsyncExecutionFlowScopeContext.Default : null);

    public static IDisposable Scope()
    {
        return _container.OpenScope();
    }

   public static IDisposable ScopeAsync()
    {
        return _container.OpenScope();
    }

If we open scope in async method and if we use async methods in the opened scope, we use ScopeAsync method, if we don't await any method in the opened scope we use Scope method. Although it is the same now, we were able to do it when we used a different Ioc library before. After switching to DryIoc, the Scope and ScopeAsync methods did the same job.

public void NonAsyncMethod()
{
   using (Ioc.Scope())
   {
       Ioc.Resolve<TService>();
   }
}

public async Task AsyncMethod1Async()
{
   using (Ioc.ScopeAsync())
   {
       ....
       await AsyncMethod2Async();
       ....
   }
}

public async Task AsyncMethod2Async()
{
     Ioc.Resolve<TService>(); // throws If AsyncExecutionFlowScopeContext is not used, the error stating that the scope cannot be found.
}

Chatgpt suggests this HybridScopeContext, but I wasn't sure about the code:

public sealed class HybridScopeContext : IScopeContext
{
    private readonly ThreadScopeContext _thread = new ThreadScopeContext();
    private readonly AsyncExecutionFlowScopeContext _async = AsyncExecutionFlowScopeContext.Default;

    internal static readonly AsyncLocal<bool> UseAsync = new AsyncLocal<bool>();

    private IScopeContext Current => UseAsync.Value ? (IScopeContext)_async : _thread;

    public IScope GetCurrentOrDefault() => Current.GetCurrentOrDefault();

    public IScope SetCurrent(SetCurrentScopeHandler changeCurrentScope)
        => Current.SetCurrent(changeCurrentScope);

    public void Dispose()
    {
        _thread.Dispose();
    }
}

public static IDisposable Scope() // thread-bound
{
    return _container.OpenScope();
}

public static IDisposable ScopeAsync() // async-flow-bound
{
    var prev = HybridScopeContext.UseAsync.Value;
    HybridScopeContext.UseAsync.Value = true;

    var scope = _container.OpenScope();
    return new ScopeCookie(scope, () => HybridScopeContext.UseAsync.Value = prev);
}

private sealed class ScopeCookie : IDisposable
{
    private IDisposable _scope;
    private readonly Action _reset;

    public ScopeCookie(IDisposable scope, Action reset)
    {
        _scope = scope;
        _reset = reset;
    }

    public void Dispose()
    {
        _scope?.Dispose();
        _scope = null;
        _reset?.Invoke();
    }
}

[oruchreis]

By the way, I tried ChatGPT's suggestion, but it didn't work either. It worked for exceptions where the scope couldn't be found, but the blazor app is throwing these exceptions as if I had set AsyncExecutionFlowScopeContext.Default in the container.

warn: Microsoft.AspNetCore.Components.Server.Circuits.RemoteRenderer[100]
      Unhandled exception rendering component: Do not call GetAuthenticationStateAsync outside of the DI scope for a Razor component. Typically, this means you can call it only within a Razor component or inside another DI service that is resolved for a Razor component.
      System.InvalidOperationException: Do not call GetAuthenticationStateAsync outside of the DI scope for a Razor component. Typically, this means you can call it only within a Razor component or inside another DI service that is resolved for a Razor component.
         at Microsoft.AspNetCore.Components.Server.ServerAuthenticationStateProvider.GetAuthenticationStateAsync()
         at Microsoft.AspNetCore.Components.Authorization.CascadingAuthenticationState.OnInitialized()
         at Microsoft.AspNetCore.Components.ComponentBase.RunInitAndSetParametersAsync()
fail: Microsoft.AspNetCore.Components.Server.Circuits.CircuitHost[111]
      Unhandled exception in circuit 'eKWXQf9RzFTHGEfqRfvugvmkz_s6LfRHqMiQ02u-oHw'.
      System.InvalidOperationException: Do not call GetAuthenticationStateAsync outside of the DI scope for a Razor component. Typically, this means you can call it only within a Razor component or inside another DI service that is resolved for a Razor component.
         at Microsoft.AspNetCore.Components.Server.ServerAuthenticationStateProvider.GetAuthenticationStateAsync()
         at Microsoft.AspNetCore.Components.Authorization.CascadingAuthenticationState.OnInitialized()
         at Microsoft.AspNetCore.Components.ComponentBase.RunInitAndSetParametersAsync()

Another error is this:

Error: System.InvalidOperationException: 'RemoteNavigationManager' has not been initialized. at 
Microsoft.AspNetCore.Components.NavigationManager.AssertInitialized() at 
Microsoft.AspNetCore.Components.Routing.Router.Attach(RenderHandle renderHandle) at 
Microsoft.AspNetCore.Components.RenderTree.Renderer.AttachAndInitComponent(IComponent component, Int32 parentComponentId) at 
Microsoft.AspNetCore.Components.RenderTree.Renderer.InstantiateChildComponentOnFrame(RenderTreeFrame[] frames, Int32 frameIndex, Int32 parentComponentId) at 
Microsoft.AspNetCore.Components.RenderTree.RenderTreeDiffBuilder.InitializeNewComponentFrame(DiffContext& diffContext, Int32 frameIndex) at Microsoft.AspNetCore.Components.RenderTree.RenderTreeDiffBuilder.InitializeNewSubtree(DiffContext& diffContext, Int32 frameIndex) at 
Microsoft.AspNetCore.Components.RenderTree.RenderTreeDiffBuilder.InsertNewFrame(DiffContext& diffContext, Int32 newFrameIndex) at Microsoft.AspNetCore.Components.RenderTree.RenderTreeDiffBuilder.InsertNewFrame(DiffContext& diffContext, Int32 newFrameIndex) at 
Microsoft.AspNetCore.Components.RenderTree.RenderTreeDiffBuilder.AppendDiffEntriesForRange(DiffContext& diffContext, Int32 oldStartIndex, Int32 oldEndIndexExcl, Int32 newStartIndex, Int32 newEndIndexExcl) at 
Microsoft.AspNetCore.Components.RenderTree.RenderTreeDiffBuilder.ComputeDiff(Renderer renderer, RenderBatchBuilder batchBuilder, Int32 componentId, ArrayRange1 oldTree, ArrayRange1 newTree) at 
Microsoft.AspNetCore.Components.Rendering.ComponentState.RenderIntoBatch(RenderBatchBuilder batchBuilder, RenderFragment renderFragment, Exception& renderFragmentException) at 
Microsoft.AspNetCore.Components.RenderTree.Renderer.ProcessRenderQueue()

[dadhi]

@oruchreis Ok, thanks.

What if there will be OpenScope accepting the context as parameter?

For instance, you may have the default container.ScopeContext provided on construction as it is working right now.
Then it is possible to provide the arbitrary context:

  _fallbackContext = new ThreadScopeContext();
  // if bla-bla condition
  _scope = _container.OpenScope(_fallbackContext);

The open problem to figure out is how scope.Dispose would remove itself from the custom scope context.
Currently, the context is not tracked inside the scope, the link is unidirectional of container holding the context, holding the scopes.
So the disposal of scope will attempt to remove the scope from container.ScopeContext and not from the one provided in OpenScope method.

But it is solvable.
Looks good to you?

[oruchreis]

What if there will be OpenScope accepting the context as parameter?

For instance, you may have the default container.ScopeContext provided on construction as it is working right now. Then it is possible to provide the arbitrary context

Thank you for your reply. Currently, when creating a container for the Blazor application, I already have to set the scopeContext parameter to null. If I haven't misunderstood you, I think the issue would be resolved if, as you mentioned, we could pass either AsyncExecutionFlowScopeContext or ThreadScopeContext to scopeContext when calling the OpenScope method, depending on the situation. This is because Blazor and MS DI will actually use a container with a null scopeContext parameter as a service provider factory, while OpenScope calls in the application could be opened as AsyncExecutionFlowScope if desired.

[oruchreis]

I've found a workaround solution, but I'm not sure how it will perform or how much memory it will use, or whether it will work properly. However, at least the Blazor application and the async flow using Openscope haven't caused any problems so far.

private class IocServiceProviderFactory: IServiceProviderFactory<IContainer>
{
    private DryIocServiceProviderFactory _innerFactory;


    public IContainer CreateBuilder(IServiceCollection services)
    {
        var preContainer = PrepareContainer();
        _innerFactory = new DryIocServiceProviderFactory(preContainer, RegistrySharing.Share);
        ServiceCollectionRegistrations(services);
        _rootContainer = _innerFactory.CreateBuilder(services);
        _container = _rootContainer.With(
            parent: _rootContainer,
            rules: _rootContainer.Rules,
            scopeContext: AsyncExecutionFlowScopeContext.Default,
            registrySharing: RegistrySharing.Share,
            singletonScope: _rootContainer.SingletonScope,
            currentScope: null,
            isRegistryChangePermitted: IsRegistryChangePermitted.Permitted
        );
        return _rootContainer;
    }

    public IServiceProvider CreateServiceProvider(IContainer containerBuilder) => _innerFactory.CreateServiceProvider(containerBuilder);
}

private static IContainer _container;
private static IContainer _rootContainer;

private static IContainer PrepareContainer(bool useAsyncLocalScopedContext)
{
    var tryInjectRequiredProperties = PropertiesAndFields.All(withFields: false, serviceInfo: TryInjectRequiredProperties);
    var container = new Container(
        Rules
            .MicrosoftDependencyInjectionRules                
            .With(propertiesAndFields: tryInjectRequiredProperties)
            .WithDefaultIfAlreadyRegistered(IfAlreadyRegistered.Replace)
            .WithCaptureContainerDisposeStackTrace()
            ,null);
    return container;
}

public static IHostBuilder IntegrateIoc(this IHostBuilder builder, bool useAsyncLocalScopedContext = true)
{
    _useAsyncLocalScopedContext = useAsyncLocalScopedContext;

    return builder
        .UseServiceProviderFactory(new IocServiceProviderFactory(useAsyncLocalScopedContext))
        .ConfigureContainer<DryIoc.Container>((hostContext, container) =>
        {
            while (_afterContainerReadyActions.TryDequeue(out var action))
            {
                action();
            }
        });
}

In summary, I am using two containers. First, I create a _rootContainer with a null scopeContext parameter according to my own rules. I then save this _rootContainer for use in the host builder. Then, to be able to use it in Resolve and OpenScope methods in the application, I create a new container using the .With method with AsyncExecutionFlowScopeContext.Default. Since the second container I created, _container, uses the same Share and SignletonScope, I believe it needs to have the same registry as _rootContainer.

[dadhi]

@oruchreis Interesting solution. Basically, you are using two different container facades to the same registry.
Performance-wise, those containers will hold on two different caches of the resolved/injected service expressions and delegates. It may affect memory consumption and performance or may not, depending on your context.