在我的团队中，我们创建程序集以附加到我公司其他地方创建和发布的可扩展发布软件。这些程序集通常特定于单个客户端，但有些会被重用。我想在这个环境中引入几个标准 - 版本号和安装程序。
目前，许多程序集在没有足够版本控制的情况下转到客户端。我想建立自动版本号更新，以便当客户遇到问题时我们可以确定他们的软件中使用了哪些源代码。
目前，程序集由个人手动复制到正确的路径并执行任何必要的注册来安装。我想强制人们使用安装程序包，以便自动处理路径和注册。
我可以通过让人们使用来实现第一步：
[assembly: AssemblyVersion("1.0.*")]
但我更喜欢更新AssemblyFileVersion而不是AssemblyVersion。这是因为我了解推进AssemblyVersion与我们的手动安装相结合可能会导致注册多个版本的程序集。 AssemblyFileVersion不会自动更新，我担心需要开发人员安装第三方工具的解决方案。如果我们有一个正确的安装过程，问题将会消失多个版本。
对于第二步，如果我使用Visual Studio安装项目，那么添加程序集会导致它尝试从原始发布的软件添加其他程序集，这是我不想要的。我假设我可以以某种方式创建它作为补丁，但我还没有这样做。当然，安装程序将需要可靠的版本号，否则事情会很糟糕。
似乎很清楚写了这篇文章我需要同时推进这两个问题，但我真的宁愿一次接近一个。
有关解决这两个问题的最佳方法的想法吗？
答案 0 :(得分：3)
我没有足够的信息指出您的解决方案。你用什么来构建你的应用程序和安装程序？桌面F5构建？ Team Foundation Server？巡航控制？
要实现的目标：
1）Visual Studio部署项目 suck 。是的，我会坚持这个评论。在您的情况下，您拥有的依赖项扫描问题是不可修复的。即使您右键单击|排除它可以在构建时扫描新依赖项的依赖项。我们甚至编写了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。
答案 1 :(得分：2)
如果这些是已发布的应用程序，那么安装程序方法就可以了。如果您通过此方法添加库，而不一定是实际的应用程序，那么NuGet（包管理器）之类的东西就是一个选项。 NuGet本身有点婴儿，需要长大一点，但我认为它应该适合你的基本情况。
如果您已发布软件，则客户端上的引导程序会调用更新，然后运行更新安装程序，这是一种很好的模式。
基本答案是你可以选择，取决于你所使用的位数，并应该利用符合你需要的那些。