.NETソリューションセットアップの更新に関するアドバイス

Question

セットアップ/ msiインストールとして展開されたwinformsアプリケーションを作成しました。 ClickOnce配置を使用していない主な理由は以下のとおりです。

1. は、現時点では「すべてのユーザー」

のためにインストールできるようにする必要がありアプリ

のディレクトリに永続的なデータストレージを必要としますアプリケーションでは「1つの.exeを使用してそれらすべてを管理する」が使用されます。基本的に、インストール後の "program files"ディレクトリには、.exe、.ico、および.configファイルがあります。

私は更新メカニズムを持つことができるように、MSDNのこのアドバイス/チュートリアルに従うことをしようとしている： http://msdn.microsoft.com/en-us/library/aa367564.aspx

私は単一の.exeを持つことが必ずしも最善のアプローチではないという印象を受けます。 .dllライブラリの作成とアプリケーションクラスのプロジェクト内での.csファイルへの配置については、「経験則」があるのでしょうか？

.exeファイルではなく一部の.dllファイルを簡単に置き換えることができますか？

Answer 1

、私は、修正再表示した、グレートホワイト北朝鮮によって与えられた答えに同意です：

1. 別々のプロジェクトに重大なサイズ/機能のアプリケーションを分割するための良い理由があります/コンポーネント。
2. .NETアプリケーションは、アセンブリをアプリケーションのディレクトリにコピーするだけでインストール/更新することができます（アセンブリが互いに互換性があるとします）。

Windowsインストーラのセットアップパッケージ（つまり、VS Deploymentプロジェクトが生成するもの）といわゆる "xcopy deployment"（すなわち、アセンブリをコピーする場所）が混在していないことを強くお勧めします。行く必要があります）。 Windowsインストーラーパッケージによってインストールされたファイルを "xcopy"して更新すると、Windowsインストーラーは "修正"しようとします。

変更されたファイルのみを含む/更新するWindowsインストーラの「パッチ」を作成することは可能ですが、その作業を試みるのは正当な理由がありませんでした。いずれにしても、VS Deploymentプロジェクトの機能を超えていることは間違いありません。

Answer 2

一般的に、私が行っている「経験則」は、ソリューションを機能性に基づいてプロジェクトに分割することです。これは他のものとの間のテストに役立ちます。

this article on MSDNの "Application-Private Assemblies"セクションからは、あなたのアプリケーション用の新しいdllをそのフォルダにドロップして、それだけで "更新"することができるようです。一般的に