DotNet 中的补丁开发
当我们在 .NET 中开发应用程序时，我们还会在开发结束时创建设置并将设置发送给客户端。客户端安装安装文件。
当我们更改代码或在应用程序中添加新功能时，我们会再次创建安装程序并返回客户端以再次安装。在这种情况下，如果安装文件大小变得很大，有没有像补丁一样的方法，当我们更改代码时，我们只需创建一个补丁并将该补丁提供给客户端？
客户端将安装该补丁将获得更改，并且以前的功能将在应用程序中完好无损。那么我如何才能在补丁的帮助下向客户端提供唯一新添加的功能或仅更改应用程序中的部分。
请详细帮助实现此类设置开发的所有步骤，因为它的重量非常轻。
谢谢
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一种简单的方法（特别是当您对程序集进行代码签名或混淆时）是将应用程序分解为许多单独的程序集 (dll)。那么如果更新代码，只需要部署实际发生变化的程序集即可。
最重要的是控制依赖关系：一开始就定义好程序集之间的接口，并添加新接口来扩展现有功能（而不是对现有接口进行“重大更改”），以便您可以对应用程序无需在补丁中部署大量程序集。 （如果有很多依赖项，您会发现在任何地方进行更改仍然需要您将几乎所有程序集部署给客户，这在某种程度上违背了目的）。
这种方法不会提供尽可能紧凑的补丁，但它非常简单且易于实现 - 并且在许多情况下它可以提供“可接受的小”补丁。它还鼓励开发人员认真考虑使用具有最小依赖性的良好模块化设计 - 因此即使您在顶部添加更复杂的修补机制，它也是值得做的（在合理范围内）。
如果使用补丁方法，我还建议定期向客户提供完整版本，因为应用的补丁越多，出现不同步的风险就越大。 （考虑一下 Windows Update 的工作方式 - 操作系统通过补丁进行增量更新，但微软时不时地发布一个服务包，将所有小补丁合并为一个大补丁，并且很少会发布全新版本的操作系统用户必须从头开始重新安装）
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)