gpt4 book ai didi

c# - 获取 .net 核心中注入(inject)服务的调用方信息

转载 作者:行者123 更新时间:2023-12-01 23:30:36 26 4
gpt4 key购买 nike

如果我将这些属性应用于某些服务,然后将其注入(inject) DI,我正在尝试确定将使用哪个 CallerMemberNameCallerFilePath 值。例如:

public class MyService: IMyService
{
public MyService([CallerMemberName] string name = null)
{
var name = name; // name is always null here
}
}

...

public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
services.AddScoped<IMyService, MyService>();
}
}

所以,我想,它是 name 变量的期望值还是我做错了什么?在这种情况下,我该如何使用 CallerMemberName?无论如何,这可能吗?

最佳答案

I'm trying to figure out which CallerMemberName or CallerFilePath value will be used if I'll apply these attributes to some service and then inject it into DI.

你不能。您的方法行不通,因为 ASP.NET Core (Microsoft.Extensions.DependencyInjection) 使用的默认 DI 系统使用动态注册,这意味着 AOT(C#-to -IL) 和 JIT(IL-to-x64)编译器都不知道 DI 服务的消费者(注意虽然注册在概念上是静态的并且只能在启动时执行 - 它只是一个错觉:您可以在运行时轻松破解默认的 DI 容器)。

作为侧边栏:唯一您的方法可行的时间是如果您有某种代码生成系统来在构建时创建对象工厂和服务工厂不使用任何运行时反射或 IL 生成。在实践中,你看到这种方法的唯一地方是在单元测试代码中使用它,测试需要严格控制每个依赖项——但它们通常是手工编写的,非常乏味和脆弱。通过 Roslyn 代码生成,我希望看到 static 服务工厂开始被更多地使用,因为它为您提供编译时保证每个依赖项都可用 - 这样您就不会在运行时遇到任何令人讨厌的意外缺少依赖项。

[CallerMemberName][CallerFilePath] 属性是由 AOT 编译器填充的,而不是 JIT 编译器,即使它是由 JIT 编译器填充的,它也不会这无济于事,因为 DI 服务的消费者不是服务构造函数的调用者

am I doing something wrong?

你是。由于我上面描述的原因。

How do I work with CallerMemberName in that case?

你不能。 CallerMemberNameAttribute 不适用于此目的。它旨在用于快速简便的日志记录、分析和跟踪。

Is it possible, anyway?

是 - 通过正确扩展 Microsoft.Extensions.DependencyInjection。请阅读 MEDI 文档以获取更多详细信息。

关于c# - 获取 .net 核心中注入(inject)服务的调用方信息,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/66332065/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com