内部ビジネスアプリケーション用のWindowsインストーラーは理にかなっていますか？

私は、この状況でよくあることについて一般的な理解を深めようとしています。

1. 次のような典型的な企業環境でインストーラーは歓迎されますか？
   • 変更管理プロセス
   • 開発/ QA /本番環境
   • さまざまな領域（ファイアウォール、データベース、ウィンドウなど）に指定された展開チーム。
2. インストーラーの作成に適しているかどうかを確認するために、アプリケーションに適用できる「リトマステスト」はありますか？*
   • インストーラーはシンプルで、すべてのアプリケーションにインストーラーが必要ですか？
   • インストーラーも適切なツールですか？
3. 開発者がインストーラーをサポートするためにWiXのようなものを学ぶことを期待するのは合理的ですか？
   • 一般的に保守性は懸念事項です。つまり、インストーラーを作成することはニッチなスキルですか？

*

たとえば、運用サーバーの共有ディレクトリにある一連のwinformアプリケーションがあります。特定のグループはこのディレクトリからアプリケーションを実行できますが、システム管理者のみが実行可能ファイルを変更できます。現在の展開プロセスでは、管理者が実行可能ファイルとライブラリを共有ディレクトリにコピー/貼り付けします。

アプリケーションは個々のユーザーのマシンにインストールされないため、これらのアプリケーションの新しいバージョンを共有ディレクトリに展開するためのインストーラーを作成するのは理にかなっていますか？

編集-

ここでの答えは確かなアドバイスを与えると感じたので、多数のアプリケーションを構築して個々のフォルダーに展開する必要がある現在のプロジェクトで思いついたことを共有したいと思いました。

Webプロジェクトの_PublishedWebsitesの動作を模倣する_PublishedApplicationsというNuGetパッケージを見つけました。NuGetパッケージをプロジェクトにインストールすると、ビルドアーティファクトを出力パスの_PublishedApplicationsディレクトリにコピーするターゲットが追加されます。この動作は、コマンドラインからMSBuildを実行し、outdirプロパティを指定することでアクティブになります。

msbuild /p:Configuration=Release /p:outdir=C:\path\to\outdir MySolution.sln

これにより、次のようなディレクトリ構造が得られます。

• C：\ path \ to \ outdir
  • _PublishedApplications \
    • Project1 \
      • dlls, exes, etc.
    • Project2 \
      • ...

そこから、さまざまな環境で抽出できるzipを作成するのは非常に簡単です。

常にインストーラー関連ファイルをフォルダにコピーしてEXEを実行するよりも複雑な展開が必要な場合、意味を持ちます。 製品を適切にセットアップするために追加の手順が必要な場合、2つの方法があります。

1. 誰かがフォローするリストを作成できます。人間は人間であり、誰かがそれを台無しにしなければならず、プログラムが正しく実行されていないので、助けを求めてあなたを呼び出します。
2. フォローするコンピューターのリストを書き出すことができます（インストールスクリプト）。これにより、ユーザーエラーによって展開が台無しになる可能性がはるかに低くなります。

一方、実行する必要のあるセットアップタスクがない場合は、zipファイルを渡してください。インストーラーを実行するよりも簡単です。

ワイアットはプログラマーの帽子を脱ぎ、ディレクターのIT帽子をかぶる

これが社内の基幹業務アプリケーションである場合は、1つの環境に向けるだけで十分です。私はITの責任者に電話して、彼らがどのように展開を管理したいかを尋ねました。IT部門はしばらくの間これに対処してきたため、xcopyまたはMSIベースのオプション、または現在のオプションなどの完全なオプションを強く好みます。

部門は少なくともジェスチャーを高く評価し、既存の基幹業務アプリと問題についてあなたが理解するより多くのことを知っている可能性があるため、貴重な味方になる可能性が高いと付け加えます。

Windowsインストーラーアプリケーションは、Windowsを使用する環境に内部ビジネスアプリケーションをインストールするために広く使用されています。また、アプリケーションの存続期間にわたって、ユーザーのシステムから更新、パッチ適用、修復、または完全に削除する必要があるかどうかを自問する必要があります。多くの場合、答えは「はい」です。その場合、適切に作成されたインストーラーを使用することで、長期にわたってアプリケーションを維持するための総コストを削減できます。Restart ManagerやWMI、製品やパッチのインベントリ機能など、Windows Installerで動作するように設計された他のサービスや機能があります。アプリケーションがこれらの恩恵を受けることができる場合、それはインストーラーを含めるもう1つの理由です。

アプリケーションに便利なインストーラーを開発するための初期費用は長期的に見返りがあり、WiXやInstallShieldなどの適切なWindowsインストーラーオーサリングツールを選択することで開発費用を軽減できます。

すべてのエンジニアリングの決定と同様に、それは異なります。

おそらく最も重要な要因は、インストールプロセスの消費者が誰であり、開発チームがどのようなスキルセットを持っているかを理解することです。

内部にあるため、内部のIT部門によって展開されていると思います。彼らはおそらくコマンドシェルを知らない人ではないでしょう。

グラフィカルインストールウィザードは、ファイルサーバーの場所、セキュリティポリシーなど、構成に関する単純な仮定がもはや有効ではないため、外部の顧客に直接配布されるソフトウェアに役立ちます。したがって、各ユーザーが設定を選択するようガイドする必要があります。

あなたの環境では、このようなものはおそらく開発またはITによって決定され、めったに変更されません。したがって、シェルスクリプトを使用してファイルを適切な場所にコピーすることをお勧めします。スクリプトは、リリースされるパッケージの一部として製品内に存在する必要があります。また、アプリとともにバージョン管理する必要があります。

私が作業している場所では、Webアプリケーション全体がInstallShieldウィザードを介してインストールされます。InstallShieldウィザードは、多くの質問をします。そのほとんどは、ファイルシステムの場所、db接続情報、その他の設定ファイルです。自動化するのは難しいです。コアでのWebアプリのインストールでは、いくつかのデータベースが作成され、ファイルがコピーされるため、AntまたはPowershellを使用して、.sqlファイルを実行してファイルをコピーする新しいインストーラーを作成しています。

そうすれば、誰もがそれがどのように機能するかを理解し、より効果的に維持できます。