ルートプロバイダーからスコープサービスを解決できません。NetCore2

83

アプリを実行しようとすると、エラーが発生します 

InvalidOperationException: Cannot resolve 'API.Domain.Data.Repositories.IEmailRepository' from root provider because it requires scoped service 'API.Domain.Data.EmailRouterContext'.

奇妙なことに、このEmailRepositoryとインターフェースは、他のすべてのリポジトリーとまったく同じように設定されていますが、エラーはスローされません。このエラーは、app.UseEmailingExceptionHandling（）;を使用しようとした場合にのみ発生します。ライン。これが私のStartup.csファイルの一部です。

public class Startup
{
    public IConfiguration Configuration { get; protected set; }
    private APIEnvironment _environment { get; set; }

    public Startup(IConfiguration configuration, IHostingEnvironment env)
    {
        Configuration = configuration;

        _environment = APIEnvironment.Development;
        if (env.IsProduction()) _environment = APIEnvironment.Production;
        if (env.IsStaging()) _environment = APIEnvironment.Staging;
    }

    public void ConfigureServices(IServiceCollection services)
    {
        var dataConnect = new DataConnect(_environment);

        services.AddDbContext<GeneralInfoContext>(opt => opt.UseSqlServer(dataConnect.GetConnectString(Database.GeneralInfo)));
        services.AddDbContext<EmailRouterContext>(opt => opt.UseSqlServer(dataConnect.GetConnectString(Database.EmailRouter)));

        services.AddWebEncoders();
        services.AddMvc();

        services.AddScoped<IGenInfoNoteRepository, GenInfoNoteRepository>();
        services.AddScoped<IEventLogRepository, EventLogRepository>();
        services.AddScoped<IStateRepository, StateRepository>();
        services.AddScoped<IEmailRepository, EmailRepository>();
    }

    public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
    {
        loggerFactory.AddConsole();

        app.UseAuthentication();

        app.UseStatusCodePages();
        app.UseEmailingExceptionHandling();

        app.UseMvcWithDefaultRoute();
    }
}

これがEmailRepositoryです

public interface IEmailRepository
{
    void SendEmail(Email email);
}

public class EmailRepository : IEmailRepository, IDisposable
{
    private bool disposed;
    private readonly EmailRouterContext edc;

    public EmailRepository(EmailRouterContext emailRouterContext)
    {
        edc = emailRouterContext;
    }

    public void SendEmail(Email email)
    {
        edc.EmailMessages.Add(new EmailMessages
        {
            DateAdded = DateTime.Now,
            FromAddress = email.FromAddress,
            MailFormat = email.Format,
            MessageBody = email.Body,
            SubjectLine = email.Subject,
            ToAddress = email.ToAddress
        });
        edc.SaveChanges();
    }

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

    private void Dispose(bool disposing)
    {
        if (!disposed)
        {
            if (disposing)
                edc.Dispose();
            disposed = true;
        }
    }
}

そして最後に、ミドルウェアを処理する例外

public class ExceptionHandlingMiddleware
{
    private const string ErrorEmailAddress = "errors@ourdomain.com";
    private readonly IEmailRepository _emailRepository;

    private readonly RequestDelegate _next;

    public ExceptionHandlingMiddleware(RequestDelegate next, IEmailRepository emailRepository)
    {
        _next = next;
        _emailRepository = emailRepository;
    }

    public async Task Invoke(HttpContext context)
    {
        try
        {
            await _next.Invoke(context);
        }
        catch (Exception ex)
        {
            await HandleExceptionAsync(context, ex, _emailRepository);
        }
    }

    private static Task HandleExceptionAsync(HttpContext context, Exception exception,
        IEmailRepository emailRepository)
    {
        var code = HttpStatusCode.InternalServerError; // 500 if unexpected

        var email = new Email
        {
            Body = exception.Message,
            FromAddress = ErrorEmailAddress,
            Subject = "API Error",
            ToAddress = ErrorEmailAddress
        };

        emailRepository.SendEmail(email);

        context.Response.ContentType = "application/json";
        context.Response.StatusCode = (int) code;
        return context.Response.WriteAsync("An error occured.");
    }
}

public static class AppErrorHandlingExtensions
{
    public static IApplicationBuilder UseEmailingExceptionHandling(this IApplicationBuilder app)
    {
        if (app == null)
            throw new ArgumentNullException(nameof(app));
        return app.UseMiddleware<ExceptionHandlingMiddleware>();
    }
}

更新：このリンクhttps://github.com/aspnet/DependencyInjection/issues/578を見つけたため、Program.csファイルのBuildWebHostメソッドをこれから変更しました。

public static IWebHost BuildWebHost(string[] args)
{
    return WebHost.CreateDefaultBuilder(args)
        .UseStartup<Startup>()
        .Build();
}

これに

public static IWebHost BuildWebHost(string[] args)
{
    return WebHost.CreateDefaultBuilder(args)
        .UseStartup<Startup>()
        .UseDefaultServiceProvider(options =>
            options.ValidateScopes = false)
        .Build();
}

正確に何が起こっているのかわかりませんが、今はうまくいくようです。

c#  asp.net-core  asp.net-core-2.0 
— geoff swartz
ソース
4
そこで起こっていることは、スコープのネストが検証されていないということです。のように、実行時にスコープレベルのネストが不適切かどうかはチェックされません。どうやら、これは1.1でデフォルトでオフにされていました。2.0が登場すると、デフォルトでオンになりました。
— ロバートバーク
ValidateScopesをオフにしようとしている人は、このstackoverflow.com/a/50198738/1027250
— Yorro

回答:

174

をIEmailRepositoryスコープサービスとしてStartupクラスに登録しました。これは、のコンストラクター注入によって解決できるのMiddlewareはSingletonサービスのみであるため、コンストラクターパラメーターとして挿入できないことを意味しますMiddleware。依存関係を次のInvokeようなメソッドに移動する必要があります。

public ExceptionHandlingMiddleware(RequestDelegate next)
{
    _next = next;
}

public async Task Invoke(HttpContext context, IEmailRepository emailRepository)
{
    try
    {
        await _next.Invoke(context);
    }
    catch (Exception ex)
    {
        await HandleExceptionAsync(context, ex, emailRepository);
    }
}
— user1336
ソース
12
うわー！メソッドに注入できることを知らなかったのですが、これはミドルウェア専用ですか、それとも自分のメソッドでこのトリックを使用できますか？
— ファーガルモラン
スコープとして登録されているIMiddlewareはどうですか？ミドルウェアの新しいインスタンスを取得することは確かですが、スコープ付きサービスをそれに注入することはできません。
— ボティス2018年
2
@FergalMoran残念ながら、この「トリック」はミドルウェアのInvokeメソッドだけの特別な動作です。ただし、autofac IoClibとプロパティインジェクションを使用して同様のことを実現できます。プロパティまたはセッターメソッドを介したASP.NETコアMVC依存性注入を参照してください。。
— B12Toaster
4
注射は魔法ではありません。コンストラクターまたはメソッドのいずれかにパラメーターとして渡すインスタンスを生成するために、実際に依存関係コンテナーを呼び出す舞台裏のエンジンがあります。この特定のエンジンは、HttpContextの最初の引数を持つ「Invoke」という名前のメソッドを探し、残りのパラメーターのインスタンスを作成します。
— ThanasisIoannidis19年
86

スコープ依存関係のインスタンスを取得する別の方法は、サービスプロバイダー（IServiceProvider）をミドルウェアコンストラクターに挿入しscope、Invokeメソッドを作成してから、スコープから必要なサービスを取得することです。

using (var scope = _serviceProvider.CreateScope()) {
    var _emailRepository = scope.ServiceProvider.GetRequiredService<IEmailRepository>();

    //do your stuff....
}

詳細については、asp.netコア依存性注入のベストプラクティスのヒントのトリックでメソッド本体のサービスの解決を確認してください。

— リディク
ソース
5
とても助かりました、ありがとう！ミドルウェアでEFコンテキストにアクセスしようとしている人にとっては、デフォルトでスコープが設定されているため、これが最適な方法です。
— ntziolis
stackoverflow.com/a/49886317/502537は、より直接的にこれを行います
— RickAndMSFT
最初はこれがうまくいくとは思いませんscope.ServiceProviderでし_serviceProviderたが、2行目ではなくやっていることに気づきました。これをありがとう。
— adam01 0119
_serviceProvider.CreateScope（）。ServiceProviderは私にとってより良いです
— XLR 87
IServiceScopeFactoryこの目的に使用するのが最善だと思います
— Francesco DM
27

ミドルウェアは常にシングルトンであるため、ミドルウェアのコンストラクターでコンストラクターの依存関係としてスコープの依存関係を持つことはできません。

ミドルウェアはInvokeメソッドでメソッドインジェクションをサポートしているため、IEmailRepository emailRepositoryをパラメーターとしてそのメソッドに追加するだけで、そこにインジェクションされ、スコープとしては問題ありません。

public async Task Invoke(HttpContext context, IEmailRepository emailRepository)
{

    ....
}
— ジョーオーデット
ソース
同様の状況で、AddTransientを使用してサービスを追加すると、依存関係を解決できました。ミドルウェアがシングルトンなので動作しないと思いましたか？少し奇妙な...
— Sateesh Pagolu
1
一時的な依存関係は、最初に作成されたWebリクエストの最後に自動的に破棄されるスコープとは異なり、手動で破棄する必要があると思います。スコープ依存関係内の一時的な使い捨ては、外側のオブジェクトが破棄される可能性があります。それでも、シングルトン内の一時的な依存関係や、一時的な存続期間よりも長いオブジェクトが良い考えかどうかはわかりません。それは避けたいと思います。
— ジョーオーデット2018年
2
この場合、コンストラクターを介して一時スコープの依存関係を挿入できますが、思ったようにインスタンス化されません。シングルトンが構築されたときに、それは一度だけ起こります。
— ジョナサン
1
ミドルウェアは常にシングルトンであるとおっしゃいましたが、そうではありません。ミドルウェアをファクトリベースのミドルウェアとして作成し、スコープ付きミドルウェアとして使用することができます。
— Harun DilukaHeshan19年
工場ベースのミドルウェアがasp.netcore2.2で導入され、ドキュメントが2019年に作成されたようです。したがって、私が知る限り、それを投稿したときの私の答えは真実でした。工場ベースのミドルウェアは、今日では優れたソリューションのように見えます。
— ジョーオーデット
4

あなたmiddlewareとservice注入するために相互に互換性があるように持っているservice経由でconstructorあなたのmiddleware。ここで、middlewareはとして作成されています。convention-based middlewareつまり、として機能し、singleton serviceサービスをとして作成していますscoped-service。したがって、を1として動作させるためscoped-service、のコンストラクタにaを注入することはできません。ただし、ここにオプションがあります。singleton-servicescoped-servicesingleton

  1. InvokeAsyncメソッドへのパラメーターとしてサービスを注入します。
  2. 可能であれば、サービスをシングルトンにします。
  3. あなたmiddlewareをfactory-based1つに変えてください。

AFactory-based middlewareはとして機能することができscoped-serviceます。したがって、scoped-serviceそのミドルウェアのコンストラクターを介して別のミドルウェアを注入できます。以下に、factory-basedミドルウェアの作成方法を示します。

これはデモンストレーション専用です。そのため、他のすべてのコードを削除しました。

public class Startup
{
    public Startup()
    {
    }

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddScoped<TestMiddleware>();
        services.AddScoped<TestService>();
    }

    public void Configure(IApplicationBuilder app)
    {
        app.UseMiddleware<TestMiddleware>();
    }
}

TestMiddleware：

public class TestMiddleware : IMiddleware
{
    public TestMiddleware(TestService testService)
    {
    }

    public Task InvokeAsync(HttpContext context, RequestDelegate next)
    {
        return next.Invoke(context);
    }
}

TestService：

public class TestService
{
}
— ハルン・ディルカ鶴山
ソース
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.