实现开发过程 - 版本控制和安装程序

Question

在我的团队中，我们创建程序集以附加到在我公司其他地方创建和发布的可扩展软件。这些程序集通常针对单个客户端，但有些被重用。我想在这个环境中引入一些标准 - 版本号和安装程序。

目前，许多程序集没有适当的版本控制就转到客户端。我想建立自动版本号更新，所以当客户有问题时，我们可以确定他们的软件使用了哪些源代码。

当前，组件由个人将其手动复制到正确的路径并执行任何必要的注册来安装。我想强制人们使用安装程序包，以便自动处理路径和注册。

我可以让人们使用实施第一步：

[assembly: AssemblyVersion("1.0.*")] 

但我更愿意更新的AssemblyFileVersion而非的AssemblyVersion。这是因为我明白，推进AssemblyVersion与我们的手动安装相结合可能会导致注册多个版本的程序集。 AssemblyFileVersion不会自动更新，我对需要开发者安装第三方工具的解决方案保持警惕。如果我们有正确的安装过程，问题会有多个版本会消失。

对于第二步，如果我使用Visual Studio安装项目，则添加程序集会导致它尝试从原始发布的软件中添加其他程序集，这是我不想要的。我想我可以以某种方式将其作为补丁创建，但我还没有完成。当然，安装程序需要可靠的版本号，否则事情会变得很糟糕。

看起来很清楚，我已经写了这个，我需要同时推进这两个问题，但我真的宁愿一次处理一个问题。

任何想法来解决这两个问题的最佳途径？

Answer 1

我没有足够的信息来指出您的解决方案。你用什么来构建应用程序和安装程序？桌面F5构建？团队基础服务器？巡航控制？

事情来实现：

1）的Visual Studio部署项目吸。是的，我会坚持这个评论。在你的情况下，你有依赖扫描问题是不可修复的。即使你右键点击|排除它可以在构建时扫描新依赖项的依赖项。我们甚至编写了Visual Studio自动化来打开项目，右键单击|排除一切，然后将其保存在生成​​机器上以避免此问题。相信我，这是一条可怕的道路。即使微软知道它很糟糕，这就是为什么它不会在Visual Studio的下一个版本中出现。使用其他工具，例如Windows Installer XML或InstallShield Limited Edition或Professional。

2）您必须更新AssemblyFileVersion。这是变更管理的核心/基础租户，它对于使Windows Installer升级和补丁发挥作用至关重要。 AssemblyVersion可以根据自己的决定进行更改，仅适用于强命名和IoC场景，如Prism，您可以在其中撰写关于构成有效注射类的规则。

3）1.0。*不是你想要的。您需要一个可以增加版本并将其传递到构建自动化的系统。你使用什么取决于你用于构建自动化的东西。我使用Team Foundation Server和CodePlex中的项目来完成我的版本。

4）你不应该在开发者机器上构建。你应该总是使用自动化脚本而不是F5的干净构建机器。

Answer 2

如果这些是已发布的应用程序，那么安装程序方法没问题。如果你通过这种方法添加库，而不一定是实际的应用程序，那么像NuGet（包管理器）是一种选择。 NuGet本身有点幼稚，需要长大一点，但我认为它应该适合你的基本情况。

如果您已发布软件，则客户端上的一个引导程序需要更新并运行更新安装程序，这是一种很好的模式。

基本的答案是你有选择，取决于你正在使用什么位，并应利用适合你的需求。