c# - 编译时/构建后依赖注入(inject) IoC？

Question

我目前使用 NInject将接口(interface)绑定(bind)到具体类型并将它们注入(inject)到我的类中。但是，据我了解，这是一个运行时事件。对我来说，如果有人想改变我的应用程序的行为，这似乎是一个攻击点。

有什么可以让我将依赖注入(inject) IoC 迁移到编译时(阅读:构建后 IL 编织/替换)吗？

---

详细说明

在我的代码中我设置了一个绑定(bind)

Bind<IFoo>().To<Foo>()
Bind<Bar>().ToSelf().InSingletonScope();

with ctor Foo(Bar dependency)

在我的应用程序的根目录(启动时)我解析了图表

var foo = kernel.Get<IFoo>();

假设我没有服务定位器 ( anti-pattern anyway right? )。所以我不再使用 kernel 了。

现在我想要一个“构建后发布编译”，用实例化器或对常量/单例的引用等替换内核的解析引擎。这样虽然我的代码看起来像这样；

var foo = kernel.Get<IFoo>();

实际上，在我的最终构建阶段更换 IL 后，它看起来像这样:

var bar = new Bar(); 
var foo = new Foo(bar);

并且不再提及 NInject。

我对这个问题的理由是我正在使用 Fody到 IL Weave 我所有的 PropertyChanged raiser，我想知道是否可以为依赖注入(inject)做类似的事情。

Answer 1

从一般的安全角度来看，使用 DI 容器不会对您的应用程序造成任何额外的威胁。

当您编写服务(例如 Web 服务或网站)应用程序时，攻击者只能在该应用程序或服务器已被破坏时更改应用程序的 DI 配置行为。发生这种情况时，服务器应被视为丢失(您将不得不重新格式化该服务器或将其完全丢弃)。 DI 不会使情况变得更糟，因为 DI 容器通常不允许从外部更改行为。你将不得不做一些非常奇怪的事情来实现这一点。

另一方面，对于在用户机器上运行的应用程序，您应该始终认为该应用程序受到威胁，因为攻击者可以反编译您的代码，在运行时更改行为等。同样，DI 不会这样做更糟的是，因为您只能保护自己免受服务边界的攻击。该客户端应用程序必须与服务器通信，并且存储您宝贵 Assets 的位置在服务边界内。例如，您永远不应将帐户密码存储在客户端的 DLL 中。不管是否加密。

但是，使用 DI 可以使攻击者更容易更改客户端应用程序的行为，尤其是当您在 XML 中配置所有内容时。但这适用于您存储在配置文件中的所有内容。如果那是你唯一的防线(无论有没有 DI)，你都完蛋了。

it seems like a point of attack if someone wanted to change the behavior of my application

请注意，任何应用程序都可以反编译、更改和重新编译。不管它是托管的(.NET、Java)还是非托管的(C++)，或者混淆与否，都无关紧要。因此，再次强调，从安全角度来看，执行运行时 DI 还是编译时 DI 并不重要。如果这是一个问题，请不要在您无法控制的机器上部署该代码。