内部ビジネスアプリケーション用のWindowsインストーラーは理にかなっていますか？
私は、この状況でよくあることについて一般的な理解を深めようとしています。 次のような典型的な企業環境でインストーラーは歓迎されますか？ 変更管理プロセス 開発/ QA /本番環境 さまざまな領域（ファイアウォール、データベース、ウィンドウなど）に指定された展開チーム。 インストーラーの作成に適しているかどうかを確認するために、アプリケーションに適用できる「リトマステスト」はありますか？* インストーラーはシンプルで、すべてのアプリケーションにインストーラーが必要ですか？ インストーラーも適切なツールですか？ 開発者がインストーラーをサポートするために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を作成するのは非常に簡単です。