编译时/构建后依赖注入IoC？

Question

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

是否有任何东西可以让我将依赖注入IoC迁移到编译时间（阅读：构建后IL编织/替换）？

---

详细说明

在我的代码中，我设置了一个绑定

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

与ctor Foo(Bar dependency)

在我的应用程序的根目录（启动时）我解析图表

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

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

现在我想要一个“post-build release-compile”，用instanciators替换内核的解析引擎，或者对constant / singleton等的引用。这样，虽然我的代码看起来像这样;

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

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

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

并且不再提及NInject。

我对这个问题的理解是，我正在使用Fody IL Weave我所有的PropertyChanged提升者，我想知道是否可以为依赖注入执行类似的操作。

Answer 1

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

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

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

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

  如果有人想改变它，它似乎是一个攻击点   我的申请行为

请注意，任何应用程序都可以反编译，更改和重新编译。无论是管理（.NET，Java）还是不管理（C ++），或者是否进行模糊处理都无关紧要。因此，从安全角度来看，无论是运行时DI还是编译时DI都无关紧要。如果这是一个问题，请不要在无法控制的计算机上部署该代码。

Answer 2

正如所讨论的那样，你所引用的理由并没有加起来。然而，Philip Laureano（Linfu作者）做了Hiro project一段时间后才进行预部署DI。不知道它是否去过任何地方......

Answer 3

我正在使用源生成器为.Net编译一个IOC容器：

https://github.com/YairHalberstadt/stronginject

您可以执行以下操作：

IFoo

如果无法解决 gradXImage = (255 * ((gradXImage - minVal) / (maxVal - minVal))); 并避免使用反射，这将为您提供编译时错误和警告。