实现开发过程——版本控制和安装程序
本文关键字：安装 程序 版本控制 开发过程 实现 | 更新日期: 2023-09-27 18:25:24
在我的团队中，我们创建程序集，以连接到我公司其他地方创建和发布的可扩展发布软件。这些程序集通常是特定于单个客户端的，尽管有些程序集是重复使用的。我想在这个环境中引入几个标准——版本号和安装程序。
目前，许多程序集转到客户端时没有足够的版本控制。我想建立自动的版本号更新，这样当客户有问题时，我们可以确定他们的软件中使用了哪些源代码。
目前，程序集是由个人手动复制到正确的路径并执行任何必要的注册来安装的。我想强制人们使用安装程序包，以便自动处理路径和注册。
我可以通过让人们使用来实现第一步：
[assembly: AssemblyVersion("1.0.*")]
但我更愿意更新AssemblyFileVersion，而不是AssemblyVersion。这是因为我知道，将AssemblyVersion与我们的手动安装相结合会导致注册程序集的多个版本。AssemblyFileVersion不会自动更新，我对需要开发人员安装第三方工具的解决方案持谨慎态度。如果我们有一个正确的安装过程，多个版本的问题就会消失。
对于第二步，如果我使用Visual Studio安装项目，则添加程序集会导致它尝试从原始发布的软件中添加其他程序集，而我不希望这样做。我想我可以以某种方式将其创建为补丁，但我还没有解决这个问题。当然，安装程序需要可靠的版本号，否则会出现问题。
写下这篇文章后，我显然需要同时推进这两个问题，但我真的更愿意一次处理一个问题。
有没有想过解决这两个问题的最佳方法？
我没有足够的信息来为您提供解决方案。您使用什么来构建应用程序和安装程序？桌面F5版本？Team Foundation Server？巡航控制？
需要实现的事项：
1） Visual Studio部署项目非常糟糕。是的，我会坚持这个评论。在您的情况下，您遇到的依赖扫描问题是无法解决的。即使右键单击|排除依赖项，它也可以在构建时扫描新的依赖项。我们甚至编写了visual studio automation来打开项目，右键单击|排除所有内容，然后将其保存在构建机器上以避免此问题。相信我，这是一条可怕的路。即使是微软也知道它很糟糕，这就是为什么它无论如何都不会出现在Visual Studio的下一个版本中。使用其他工具，如Windows Installer XML或InstallShield Limited Edition或Professional。
2） 您必须更新AssemblyFileVersion。这是变更管理的核心/基础租户，对于Windows Installer升级和补丁的运行至关重要。AssemblyVersion可以根据您的判断进行更改，并且仅适用于强命名和IoC场景，如Prism，在这些场景中，您可以编写关于什么构成用于注入的有效类的规则。
3） 1.0.*不是你想要的。您需要一个系统来增加您的版本并将其传递到构建自动化中。您使用的内容将取决于您用于构建自动化的内容。我使用TeamFoundationServer和CodePlex中的一个项目来完成我的翻版。
4） 您永远不应该在开发人员机器上进行构建。您应该始终使用带有自动脚本的干净构建机器，而不是F5。
如果这些是已发布的应用程序，那么安装程序方法就可以了。如果您通过这种方法添加库，而不一定是实际的应用程序，那么像NuGet（包管理器）这样的东西是一个选项。NuGet本身有点幼稚，需要长大一点，但我认为它应该适合你的基本场景。
如果您已经发布了软件，那么在客户端上调用更新并运行更新安装程序的引导程序是一种很好的模式。
基本的答案是，你有选择，这取决于你正在使用的部分，并且应该利用适合你需求的部分。