我目前使用NInject将接口绑定到具体类型，并将它们注入到我的类中。然而，据我所知，这是一个运行时事务。对我来说，如果有人想改变我的应用程序的行为，这似乎是一个攻击点。
是否有任何东西可以让我将依赖注入IoC迁移到编译时(阅读：构建后IL编织/替换(
详细说明
在我的代码中，我设置了一个绑定
Bind<IFoo>().To<Foo>()
Bind<Bar>().ToSelf().InSingletonScope();
带ctor Foo(Bar dependency)
在我的应用程序的根(在启动时(，我解析图形
var foo = kernel.Get<IFoo>();
假设我没有服务定位器(无论如何都是反模式的，对吗？(。所以我不再使用kernel了。
现在，我想要一个"构建后发布编译"，用实例化器或对常量/单例的引用等替换内核的解析引擎。这样，虽然我的代码看起来是这样的；
var foo = kernel.Get<IFoo>();
事实上，在我的最后构建阶段更换IL后，它看起来是这样的：
var bar = new Bar();
var foo = new Foo(bar);
并且不再提及NInject。
我对这个问题的理性是，我正在使用Fody来IL Weave我所有的PropertyChanged筹款人，我想知道是否有可能对依赖注入做类似的事情。
通常从安全角度来看，DI容器的使用不会对应用程序造成任何额外的威胁。
当您编写服务(如web服务或网站(应用程序时，只有在应用程序或服务器已被破坏时，攻击者才能更改该应用程序的DI配置行为。当这种情况发生时，服务器应该被视为丢失(您将不得不重新格式化该服务器或将其完全丢弃(。DI并没有让情况变得更糟，因为DI容器通常不允许从外部更改行为。你必须做一些非常奇怪的事情才能做到这一点。
另一方面，对于在用户机器上运行的应用程序，您应该始终认为该应用程序受到了攻击，因为攻击者可以反编译您的代码，在运行时更改行为等。同样，DI不会让情况变得更糟，因为您只能保护自己免受服务边界上的攻击。该客户端应用程序必须与服务器通信，并且存储您宝贵资产的位置在服务范围内。例如，您永远不应该将帐户密码存储在客户端的DLL中。不管它是否加密。
然而，DI的使用可以使攻击者更容易地更改客户端应用程序的行为，尤其是当您用XML配置所有内容时。但这适用于存储在配置文件中的所有内容。如果这是你唯一的防线(无论有没有DI(，你无论如何都会失败。
如果有人想改变我的应用程序的行为
请注意，任何应用程序都可以反编译、更改和重新编译。不管它是托管的(.NET、Java(还是非托管的(C++(，或者是模糊的还是非模糊的。因此，从安全角度来看，无论是执行运行时DI还是编译时DI都无关紧要。如果这是一个问题，不要将代码部署在您无法控制的机器上。
正如所讨论的，您引用的这样做的原因并不一致。然而，Philip Laureano(林夫的作者(在一段时间前做了一个Hiro项目，该项目进行预部署DI。不知道它是否去了哪里。。。
我正在为.Net开发一个编译时IOC容器，该容器使用源生成器：
https://github.com/YairHalberstadt/stronginject
https://www.nuget.org/packages/StrongInject/
有了它，你可以做以下事情：
using StrongInject;
[Registration(typeof(Foo), typeof(IFoo))]
[Registration(typeof(Bar), Scope.SingleInstance)]
public class Container : IContainer<IFoo> {}
public static class Program
{
public static void Main()
{
new Container().Resolve(foo => //use foo here);
}
}
如果不能解析IFoo并避免使用反射，这将给您提供编译时错误和警告。