「Visual Studio セットアップ」プロジェクトは、異なるバージョンでの複雑なセットアップに適していますか?
アプリケーションはかなり大きく (500,000 行以上のコード)、継続的に開発中です。6 ～ 10 か月ごとに新しいバージョンがリリースされます。複数の構成ファイル (INI および XML)、レジストリ キー、データベース移行スクリプトなどがあります。アプリケーションはVisual Basic 6.0から .NET に移行中です。古いインストーラーはInstallshieldでビルドされていました。Installshieldへのフィードバックは次のとおりです: 適応性が悪い、再利用が悪い - そのため、"Visual Studio セットアップ" を代替手段として評価しています。
私たちが検討する他の製品：
考慮したくないソリューション:
いいえ、いいえ、いいえ、いいえ、Visual Studio 展開プロジェクトにはありません。私は「大規模な」プロジェクト (VDPROJ はサービスの作成などの基礎となる MSI をほとんど公開しないため、数千のマージ モジュールと数百の InstallUtil カスタム アクションを含む 15,000 ファイル) に参加しました。それが本当にどれほど恐ろしいことかについて、私は何時間も続けることができました。
私には 4 人のインストール開発者のチームがあり、 WiXとInstallShieldを組み合わせて使用しています。私たちの典型的なインストールには、ほぼ 100 の機能、800 のマージ モジュール、および 15,000 のファイルがあります。完全な製品またはシステムを作成するためのサードパーティのインストールの連鎖を含め、想像できるほぼすべてのタイプのリソースをデプロイします。複数の統合、リリース、およびメンテナンス ブランチから構築された 12 を超える製品に対して、これを行うことができます。私たち 4 人は、約 250 人の開発者を持つ 400 人以上の組織をサポートしています。
これができるのは、InstallShield が実際にかなりの量の再利用を提供できるからです。製品構成と機能/マージ モジュールを使用して、ファイルとビジネス ロジックのグループのカプセル化を作成します。それでも、WiX の方が優れた仕事をします (ただし、学ぶのははるかに難しく、所々に InstallShield が必要な穴があります)。そのため、可能であればベースラインをゆっくりと WiX に移行しています。
そこに行かないでください！いくつかの単純なインストーラーでは実行可能だと思っていましたが、悪夢であることが判明しました... 一見すると、VS セットアップ プロジェクトは問題ないように見えますが、すぐにさまざまな欠陥に気付くでしょう。最も単純なタスクを実行するための一連のカスタム アクション コード (たとえば、サービスの処理と、「適切な」セットアップ プロジェクト GUI からアクセスできない明確に定義された特別なディレクトリへのインストール)。
ユーザー入力を取得するために使用できるのは、いくつかの非常に基本的なフォームのみです (たとえば、パスワードの入力はできません)。インストーラーのバージョン番号の自動インクリメントはありません。ファイルの取り扱いはひどいものです。すべてのファイルを手動で選択する必要があります。つまり、「このディレクトリ内のすべてのファイルをそのディレクトリにインストールする」とだけ言うことはできません。何百ものファイルがあるディレクトリ内の新しいファイルを座って手動でスキャンするのは素晴らしい作業です。
いいえ、WiX に行きましょう。学習曲線は VS インストーラーよりも少し悪いように見えるかもしれませんが、そうしなかったことを何度も後悔しています。