適切に作成およびコンパイルされた.NET2.0アセンブリは、おそらく実際には.NET 2.0、3.0、3.5(CLR 2.0)または.NET 4.0 / 4.5(CLR 4.0)に依存しています。したがって、.NET2.0以降が必要であると言った方がおそらく正確です。
とはいえ、マージモジュールはパズルのほんの一部にすぎません。この表現をどのようにデザインするかはあなた次第であり、これが私がそれを行うことを検討する1つの方法です。
.NETをインストールするのはマージモジュールの仕事ではありません。実際、マシンごとに1つの実行シーケンスを強制するWindowsInstallrミューテックスが原因ではありません。これは、MSIの仕事でもないことを意味します。ここで、ブートストラッパーとチェイナーが登場します。
MSIができることは、チェイナーがその仕事をしたことを再確認することです。また、この式は、MSIまたはマージモジュールで作成できます。
まず、AppSearch/Reglocatorをオーサリングして.NETを検出します。WiX NetFx拡張機能には、これを簡単にするために参照できるいくつかの組み込みプロパティがあります。
次に、LaunchConditionを作成します。ただし、WiXでは、Condition要素はマージモジュールに存在しません。これは、MSDNがMergeModulesがLaunchConditionテーブルを使用すべきではないと言っているためです。代わりに、タイプ19エラーのカスタムアクションを作成し、テーブルでシーケンスします。
ここで、MSIがチェックをオーバーライドできるようにする条件をこのチェックに設定することをお勧めします。(DOTNETFRAME20FOUNDおよびIGNOREDOTNETFRAME20ではありません)。実際、これらすべてをマージモジュール(REQUIRESDOTNETFRAME20.msm)に入れて、同じ依存関係を共有する複数のマージモジュールで参照することをお勧めします(繰り返さないでください)。
私の最後の仕事では、製品ラインの開発を行いました。つまり、数千のマージモジュールをさまざまな組み合わせで組み合わせて、数十の製品を作成しました。これらすべてを独自のモジュールで表現し、通常、サービスファミリ/コンポーネントレイヤーではなく、製品レイヤーで関連付けを作成しました。それが異常な依存関係である場合、時々私たちはそうしました。