コンパイル時IOC

誰かがコンパイル時にIOCを実行するプロジェクトを開始しましたか（おそらくRoslynまたはLinq MethodInfoを使用して）。

IOCコンテナーでの私の経験はこれまでのところ素晴らしく、いくつかの小さな問題がありませんでした

1. 多くのIOCコンテナは、ここで解決ロジックの多くが発生するため、起動が遅くなります
2. コンパイルがコンストラクターの呼び出しを保証しないため、解決が可能かどうかを確認するのは難しい場合がよくあります。
3. 多くの場合、IOCコンテナーはランタイムに小さなオーバーヘッドを追加します（一部は小さくもなく、多くの場合、すぐに起動するものはゆっくり実行されます）

理想的な解決策は、IOCの代わりにFactoryクラスを追加するコンパイル手順をビルドチェーンに追加することだと思われます。

誰もこれをやったことがありますか？そうでない場合は、なぜですか？

これを行うことはそのような問題ではないはずです。同じIoCロジックを実行するだけで、クラスをインスタンス化する代わりに、インスタンス化を行うコードを出力します。

しかし、これを行うことにより、IoCの大きな利点の1つ、つまり、アプリケーション全体を再コンパイルすることなく、コンポーネントの構成方法を変更することができなくなります。構成を置き換えるだけで、アプリケーションにさまざまなサービスまたはデータソースを使用させることができます。そして、この機能を最大限に活用するアプリケーションはまだ見ていませんが、それでもIoCの成功の大部分を占めています。

Dagger for Java / Androidはそれを行います。ほとんどのランタイムエラーをコンパイルエラーに変換するなど、ほぼ完全にコンパイル時のコード生成エクスペリエンスを提供するために、ランタイムマジック（Guiceのような）を犠牲にします。

.NETでもクールになります。