2

今日、Visual Studio セットアップ プロジェクトでカスタム アクションを使用して、通常は InstallUtil を使用して実行する独自のインストーラー クラスを実行できることを誰かと話し合っていました (これは、私が取り組んでいる新しいプロジェクトでうまく機能します)。

その人は、カスタム アクションを使用する必要がある場合は、独自の解決策を考え出す必要があると述べ、カスタム アクションを使用する必要があると述べ、これは多くの人に認識されており、長い間使用されてきたものであると述べました。時間。

私は周りを検索しましたが、誰もがこれについて懸念を表明している単一のフォーラムを見つけることができません.カスタムアクションを使用すべきではない理由を誰かが知っているかどうか知りたいですか?

新しいプロジェクトで可能な限り最も信頼性の高いソリューションを使用していることを確認したいのですが、これにより現在のアプローチについて懸念が生じていますが、それについて話し合っていた人は、それが悪い理由の例を教えてくれませんでしたという考えなので、彼らの言ったことが理にかなっているのかどうかを確認したいだけです。

4

1 に答える 1

2

理由はたくさんありますが、それは長くて主観的な会話です。ここにいくつかのリンクがあります。要約すると、心に留めておくべきことは、MSI の宣言型ネイティブ (オーサー テーブル データ ドリブン、トランザクション カスタム アクション) を維持し、インストーラーに脆弱性を導入しないように非常に懸命に作業することです。InstallUtil / Installer クラスのカスタム アクションの設計上、これらは単なるスターターではありません。代わりに、WiX の DTF ( Deployment Tools Foundation ) マネージ カスタム アクション プロジェクト タイプ ( C# / VB.NET ) を使用してください。

マネージ コードの CustomActions、途中でサポートされていません。その理由は次のとおりです。

カスタム アクションは (一般に) 失敗を認めるものです。

最初のリンクでは、DTF のリリースにより「技術」部分が OBE になっていることに注意してください。戦略的な部分はやや楽観的な IMO であり、2 番目のリンクで詳しく説明します。また、私自身のブログからいくつかの背景を引用します。

MSI と .NET

イデオロギーの代償と大きな新たな希望

Deployment Tools Foundation (DTF) 管理のカスタム アクション

于 2012-05-22T17:35:05.820 に答える