我们是否需要在asp.net mvc网站项目中使用Assembly版本号？

Question

情况 - 我们有一个带有WCF层的.net mvc解决方案。该解决方案有大约20个编译成DLL的奇怪项目。该网站在SQL Server 2008上运行。我们将解决方案文件夹中的SQL脚本作为版本进行维护。所以我们有SQL脚本例如。可以说最新的是3.0.0.1版本1.0.0.0。

的解决办法是在源头控制TFS，我们还可以使用TFS来管理工作项，缺陷等等等等SQL脚本文件也可以在TFS

问题 - 问题是，我们是否需要对版本号集合即dlls也。我们的DLLS没有以任何方式暴露出来，或者从外部世界中暴露出来，他们只是在mvc应用程序的运行时间中暴露出来。我们不会将WCF公开给外部客户端，它也只是由mvc应用程序使用。

部署过程简单地说就是针对最新数据库的最新代码，所以当我们部署时我们会检查数据库的版本，并运行一个工具将其升级到解决方案中数据库项目中的最新版本。

我们的一位高级架构师说我们应该维护程序集中的版本号。我说我们不需要代码中的任何版本号。因为TFS管理着这一点。当我们发布时，我们只是使用最新的程序集/部署软件包部署最新的代码。

我还没来翻过大会版本，除非他们在那里组装释放到外部世界（如果你知道我的意思）

请你可以建议...另外请注意，我们不这样做的功能开发它只是版本数字，以便我们知道特定数据库的版本。

Answer 1

我宁愿知道的安全性和能够仔细检查版本。如果出版过程出现问题，或者出现了一个似乎是出版问题的错误，我会尽可能快地排除错误。我还认为，实现这个过程很容易，你花更多的时间讨论和思考它，而不是实际上花在做这件事上，而且我没有想到的一面。

Answer 2

在我工作的类似项目中，我们使用版本号。

对版本控制系统（VCS）的每次提交都会导致我们的CI服务器（TeamCity）构建一个新的工件，并将版本设置为“最新”。每个成功的“最新”版本都会自动部署到我们的测试环境中。理论上，我们也可以将这个“最新”版本部署到生产中，但我们不这样做。

当我们想要将新版本部署到生产环境中时，我们运行一个不同的手动构建作业来创建版本化版本（例如1.4.7）。构建作业还会创建当前代码库的SVN "Tag"。为了让我们的DLL具有合适的版本，我们使用TeamCity的AssemblyInfo Patcher功能。这样，我们不必经常手动更新项目的AssemblyInfo.cs文件。相反，他们总是拥有这样的占位符版本信息...

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

这些数字在TeamCity构建期间会自动更新。版本化的构件（包括任何相应的SQL脚本）被保存到我们的“发布”目录，我们保留我们所有版本的代码库。

现在，这一切似乎是矫枉过正，对吧？ 不是。

这给了我们以下好处...

• 我们的部署过程中做了wget我们的监控页面列出的版本号，并声称该版本匹配预期已部署对（版本当前在服务器上运行的版本）。这使我们相信我们的部署过程正常工作。
• 如果在版本化版本（生产版本候选版本）中发现错误，我们可以使用SVN checkout标签，应用修补程序并创建新版本，而不必担心可能会影响发行版的其他主干上的更改。很难一直保持“可释放”状态，这不会是必须的。虽然，不要误解我的意思，it has it's advantages。
• 如果在版本化版本中发现问题，但无法快速解决问题，则始终可以重新部署已知工作的较旧工件。能够将已部署的版本恢复为旧版本，已经为我们节省了一些时间。
• 如果在需要调查的生产中发现错误，我们可以自由地将相同的版本化工件部署到我们的任何测试环境，以便我们可以尝试在生产环境之外重现问题。

我现在可能忘记了更多的优点，但上面的列表应该给出适当的版本管理可以带来的功效的一般概念。

我会建议不断，手动更新20+项目的版本文件。这看起来像是忙碌的工作，这大多是浪费时间，因为它容易出现人为错误。无论您决定要做什么，都要将其自动化并验证结果。