实施开发流程 - 版本控制和安装程序
在我的团队中，我们创建程序集以附加到我公司其他地方创建和发布的可扩展发布软件。这些程序集通常是特定于单个客户端的，尽管有些程序集会被重复使用。我想在这个环境中引入几个标准 - 版本号和安装程序。
目前，许多程序集在没有足够版本控制的情况下交付给客户端。我想建立自动版本号更新，这样当客户遇到问题时，我们可以确定他们的软件中使用了哪些源代码。
目前，程序集是由个人手动将其复制到正确的路径并执行任何必要的注册来安装的。我想强制人们使用安装程序包，以便自动处理路径和注册。
我可以通过让人们使用来实现第一步：
[assembly: AssemblyVersion("1.0.*")]
但我更愿意更新 AssemblyFileVersion 而不是 AssemblyVersion。这是因为我知道，推进 AssemblyVersion 与我们的手动安装相结合可能会导致注册程序集的多个版本。 AssemblyFileVersion 不会自动更新，而且我对要求开发人员安装第三方工具的解决方案持谨慎态度。如果我们有正确的安装过程，多个版本的问题就会消失。
对于第二步，如果我使用 Visual Studio 安装项目，那么添加程序集会导致它尝试从原始发布的软件中添加其他程序集，这是我不想要的。我想我可以以某种方式将其创建为补丁，但我还没有解决这个问题。当然，安装程序需要可靠的版本号，否则事情会变得很糟糕。
写这篇文章似乎很清楚，我需要同时推进这两个问题，但我真的宁愿一次处理一个问题。
对于解决这两个问题的最佳方法有什么想法吗？
In my team we create assemblies to attach to extensible released software created and published elsewhere in my company. These assemblies are often specific for an individual client, though some are reused. I want to introduce a couple of standards into this environment - version numbers and installers.
Currently, many assemblies go to clients without adequate versioning. I want to institute automated version number updates so when a client has a problem we can be sure which source code was used in their software.
Currently, assemblies are installed by the individual copying them manually to the correct path and performing any necessary registration. I want to force people to use an installer package so the path and registration is handled automatically.
I could implement the first step by getting people to use:
[assembly: AssemblyVersion("1.0.*")]
But I'd prefer to update the AssemblyFileVersion rather than the AssemblyVersion. This is because I understand that advancing AssemblyVersion combined with our manual installation can lead to multiple versions of an assembly being registered. AssemblyFileVersion doesn't update automatically, and I'm wary of a solution that requires developers install 3rd party tools. If we had a proper installation process, the problem would multiple versions would go away.
For the second step, if I use a Visual Studio setup project then adding the assembly causes it to try to add other assemblies from the original published software, which I don't want. I assume I can create this as a patch somehow, but I've not worked that out yet. Of course, an installer will require reliable version numbers or things will go badly.
It seems clear having written this that I need to advance both issues simultaneously, but I'd really rather approach one at a time.
Any thoughts for the best way to get over these two issues?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我没有足够的信息来为您提供解决方案。您使用什么来构建应用程序和安装程序？桌面 F5 构建？团队基础服务器？巡航控制？
需要意识到的事情：
1) Visual Studio 部署项目很糟糕。是的，我会坚持这个评论。就您而言，您遇到的依赖关系扫描问题是无法修复的。即使您右键单击 |排除它可以在构建时扫描新依赖项的依赖项。我们甚至编写了 Visual Studio Automation 来打开项目，右键 | |排除所有内容，然后将其保存在构建机器上以避免此问题。相信我，这是一条可怕的路。甚至 Microsoft 也知道它很糟糕，这就是为什么它不会出现在 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。
I don't have nearly enough information to point you to a solution. What are you using to build your application and installers? Desktop F5 build? Team Foundation Server? Cruise Control?
Things to realize:
1) Visual Studio Deployment Projects suck. Yes, I'll stick by that comment. In your case, the dependency scanning problem you have is unfixable. Even if you right click | exclude the dependency it could scan a new dependency at build time. We even wrote visual studio automation to open the project, right click | exclude everything and then save it on the build machine to avoid this problem. Trust me, it's a horrible road to go down. Even Microsoft knows it sucks and that's why it won't be in the next release of Visual Studio anyways. Use other tools such as Windows Installer XML or InstallShield Limited Edition or Professional.
2) You must update AssemblyFileVersion. This is such a core/foundational tenant of Change Management and it's critical in getting Windows Installer upgrades and patches to work. AssemblyVersion can be changed at your discretion and is only applicable to Strong Naming and IoC scenarios such as Prism where you write rules on what constitutes a valid class for injection.
3) 1.0.* isn't what you want. You want a system that increments your version and passes it into your build automation. What you use will depend on what you are using for build automation. I use Team Foundation Server and a project in CodePlex to do my versioining.
4) You should never be building on a developers machine. You should always be using a clean build machine with automated scripts and not F5.
如果这些是已发布的应用程序，则安装程序方法就可以。如果您通过此方法添加库，而不一定是实际的应用程序，那么像 NuGet（包管理器）这样的东西是一个选择。 NuGet 本身有点婴儿，需要成长一点，但我认为它应该适合您的基本场景。
如果您已发布软件，则客户端上的引导程序调用更新然后运行更新安装程序是一个很好的模式。
基本答案是您有选择，具体取决于您使用的位，并且应该利用适合您需求的位。
If these are released applications, then the installer method is fine. If you are adding libraries through this method, and not necessarily the actual application, then something like NuGet (package manager) is an option. NuGet itself is a bit infant and needs to grow up a bit, but I think it should fit your basic scenario.
If you have published software, a bootstrap on the client that calls for updates and then runs the update installer is a good pattern.
The basic answer is you have options, depending what bits you are employing and should take advantage of the one(s) that fit your needs.