Patch development in DotNet

when we develop application in .NET then we create also setup at the end of development and send the setup to client. client install the setup file.

when we change our code or add new functionality in our apps then we create setup again and give back the client to install again. in this scenario if the setup file size become huge, is there any way out like patch that when we change in our code then we just create a patch and give that patch to client?

client will install that patch will get the开发者_高级运维 changes and also previous functionality will be intact in application. so how could i give the only newly added functionality or change only part in the apps to client with the help of patch.

please help in detail with all the steps to implement this sort of setup development because it will be very light weight.

thanks

One simple approach (especially if you are code-signing or obfuscating your assemblies) is to break your application up into a number of separate Assemblies (dlls). Then if you update the code, you only need to deploy the assemblies that have actually changed.

The most important thing is to control the dependencies: define the interfaces between the assemblies well at the beginning, and add new interfaces to extend the existing functionality (rather than making "breaking changes" to existing interfaces) so that you can make useful changes to the application without having to deploy lots of assemblies in your patch. (If there are many dependencies you will find that making a change anywhere will still require you to deploy almost all of the assemblies to the customer, which defeats the purpose somewhat).

This approach won't deliver the most compact patches possible, but it's extremely simple and easy to implement - and in many cases it can provide "acceptably small" patches. It also encourages developers to think hard about using good, modular designs with minimal dependencies - so it's worth doing (within reason) even if you add a more sophisticated patching mechanism on top.

If using a patch approach I'd also advise giving the customer a full version periodically, as the more patches you apply, the greater the risk of something getting out of sync. (Consider the way Windows Update works - The OS is incrementally updated with patches, but every now and then Microsoft issues a service pack that rolls all the small patches into one large patch, and less frequently they release a whole new version of the operating system that users must reinstall from scratch)