.NETでアプリケーションを開発すると、開発の最後にセットアップも作成し、クライアントにセットアップを送信します。クライアントがセットアップファイルをインストールします。DotNetのパッチ開発
私たちのコードを変更したり、アプリケーションで新しい機能を追加したりすると、セットアップが再度作成され、クライアントにインストールし直して再度インストールすることができます。このシナリオでは、セットアップファイルのサイズが大きくなった場合、パッチのような方法がありますか？コードを変更すると、パッチが作成され、そのパッチがクライアントに渡されます。
クライアントはこのパッチをインストールして変更を適用し、以前の機能はアプリケーションにそのまま反映されます。だから、私は唯一の新しく追加された機能を与えるか、またはパッチの助けを借りてクライアントにアプリケーションの一部だけを変更することができます。
非常に軽量であるため、この種のセットアップ開発を実装するためのすべての手順を詳細にお役立てください。
おかげ
一つの簡単な方法は、（あなたがコード署名またはあなたのアセンブリを難読化されている場合は特に）別のアセンブリ（DLL）が多数にあなたのアプリケーションを分割することです。次に、コードを更新する場合、実際に変更されたアセンブリのみを展開する必要があります。
最も重要なことは、依存関係を制御することです。最初からアセンブリ間のインタフェースを定義し、新しいインタフェースを追加して既存の機能を拡張します（既存のインタフェースに「変更を加える」）。パッチに多数のアセンブリを配備しなくても、アプリケーションを便利に変更できます。 （多くの依存関係がある場合は、どこでも変更を加えることで、ほぼすべてのアセンブリを顧客に展開する必要がありますが、これは目的を多少犠牲にします）。
このアプローチでは、可能な限りコンパクトなパッチを提供することはできませんが、実装が非常に簡単で簡単です。多くの場合、「受け入れがたいほど小さな」パッチが提供されます。また、開発者は依存性の少ない優れたモジュラーデザインを使用することを熟考することを推奨します。より洗練されたパッチメカニズムを追加したとしても、（理由があれば）実行する価値があります。
パッチアプローチを使用している場合は、定期的に顧客にフルバージョンを提供することをお勧めします。適用するパッチが多いほど、同期が外れる危険性が高くなります。 （Windows Updateの仕組みを考えてください - OSはパッチで段階的に更新されていますが、今はすべての小さなパッチを1つの大きなパッチにするサービスパックを発行しますが、新しいバージョンのオペレーティングシステムユーザーはゼロから再インストールする必要があります）