コンパイル時/ビルド後の依存性注入IoC？

Question

私は現在、NInjectを使用して、コンポジットタイプにインターフェイスをバインドし、それらをクラスに注入します。しかし、これは実行時の問題だと私は理解しています。誰かが自分のアプリケーションの振る舞いを変えたいと思えば、それは私にとっては攻撃のように思えます。

コンパイル時に依存性注入IoCを移行することができるものはありますか（Read：ビルド後IL織り/置換）？ （起動時に）自分のアプリケーションのルートにctorのFoo(Bar dependency)

で

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

を結合私のコードのIセットアップで

を詳しく説明し

---

私はグラフを解決する

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

サービスロケータがないとします。（anti-pattern anyway right?）です。だから私はもうkernelのための使用がありません。

今は、カーネルの解決エンジンをinstanciator、または定数/シングルトンなどの参照に置き換える "ビルド後のリリースコンパイル"をしたいと思います。実際には

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

、私の最終ビルドの段階でILを交換した後、それは次のようになります。

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

そしてNInjectへの参照はもうありません。

私はFodyをILに使用しています。すべてのPropertyChangedライザーを織り、Dependency Injectionのために同様のことを実行できるかどうかは疑問です。

Answer 1

説明したように、これを行うためのあなたの引用された理由は合わない。しかし、Philip Laureano（Linfuの著者）は、Hiro projectをしばらく前に展開しました。それがどこに行ったか分かりません...

Answer 2

一般的なセキュリティの観点から、DIコンテナを使用しても、アプリケーションに余計な脅威は生じません。

サービス（WebサービスやWebサイトなど）アプリケーションを作成するとき、攻撃者はアプリケーションまたはサーバーが既に侵害されている場合にのみ、アプリケーションのDI構成動作を変更できます。これが起こると、サーバーは失われたとみなされます（サーバーを再フォーマットするか、完全に破棄する必要があります）。 DIコンテナは通常、外部から動作を変更することができないため、DIはこれを悪化させません。あなたはこれを実現させるために何か非常に奇妙なことをしなければなりません。

一方、ユーザのマシン上で実行されるアプリケーションでは、攻撃者がコードを逆コンパイルしたり、実行時に動作を変更したりする可能性があるため、常にそのアプリケーションを危険にさらすことを検討する必要があります。サービスの境界への攻撃から身を守ることができるだけであるため、この悪化します。そのクライアントアプリケーションはサーバーと通信する必要があり、貴重な資産を格納する場所はサービスの境界内にあります。たとえば、クライアントのDLLの中に決してアカウントパスワードを保存しないでください。それが暗号化されているかどうかにかかわらず。

しかし、DIを使用すると、特にXMLですべてを構成するときに、攻撃者がクライアントアプリケーションの動作をやや簡単に変更できるようになります。しかし、これは設定ファイルに格納されているすべてのものに当てはまります。そして、それがあなたの唯一の防衛線（DIの有無に関係なく）なら、あなたはとにかく釘付けになります。

誰かが自分のアプリケーション

の 動作を変更したい場合は、任意のアプリケーションは、逆コンパイル変更し、再コンパイルすることができますので、予めご了承ください攻撃のポイントのように思えます。それが管理されているか（.NET、Java）、そうでないか（C++）、または難読化されているかどうかは関係ありません。つまり、セキュリティの観点からは、ランタイムDIを実行するのかコンパイル時間DIを実行するのかは関係ありません。これが問題の場合は、制御できないマシンにそのコードを展開しないでください。