我收到了一份早期的圣诞礼物：
允许退出开发周期以重新组织和记录我们的应用程序。
我有完全的自由来重组、重构和设置我认为合适的任何数量的基础设施。
如果您有全权委托，那么您的“完美”.NET 开发环境是什么？
关于应用程序：
VB.NET 客户端-服务器应用程序。（Windows Forms 前端，ASPX Webservices 后端）
目前使用 Visual Studio 和 SQL Server 2003 和... Visual SourceSafe。
我想要一些组合：
* 更好的版本控制。（倾向于 Subversion）
* Wiki 或其他用于错误跟踪和文档的系统。（倾向于使用 Subversion
的Trac
） * 简化的构建过程和日常构建（Visual Build？CruiseControl.NET？）
* SQL Server 数据库的版本控制
* 升级到 Visual Studio 2005（或 2008）？
... 对于一个由 5 人左右的开发人员组成的小团队
我认为你们都在朝着正确的方向倾斜。
使用 Visual Studio 2008。它在 SP1 中非常稳定，您可以针对 .NET 框架的版本 2 和版本 3。
无论您投入多少时间和思想，您都可能永远不会得到一个“完美”的环境。每个工具都有自己的夸克和问题。不过，这里有一些值得深思的地方：
转到最新最好的 Visual Studio 版本，Visual Studio 2008 SP1。
如果您是 MSDN 订阅者，并且购买了 Visual Studio 的 Team System 版本，则可以安装Team Foundation Server(TFS)。TFS 是一个非常漂亮的产品，集成到 Visual Studio 中。它使用 Windows Sharepoint Services (WSS)，这将使您能够拥有 wiki、文档存储库等（基本上是 Microsoft Office Sharepoint Server 的精简版）。TFS 还将为您提供最新版本的 Visual SourceSafe，我对此没有任何问题，Microsoft 谈到它能够扩展到数十万用户。TFS 工作组版将允许您最多 5 名开发人员使用，而无需购买许可证。超过 5 个用户，您必须购买许可证。我也很确定您必须使用 SQL Server 2005 才能运行 TFS，但我可能错了。我们将 TFS 安装在一个盒子（我们的开发者盒子）上，并且没有任何问题。
SO TFS 会给你：
对于您的日常和持续构建，我倾向于CruiseControl.NET (CC.NET)。我们尝试使用 TFS 中内置的构建系统，但遇到了很多很多问题（我认为主要是因为我们项目的结构方式）。CruiseControl.NET 的安装和配置轻而易举，而且运行起来就像一个冠军。您可以将其设置为持续构建（每次签入触发构建）和每日构建。您可能必须找到一些更巧妙的方法来让 CruiseControl.NET 完成一些更困难的任务（如停止服务等），但它无法完成我需要完成的任何事情。它也非常可扩展，所以你可以编写一些代码来让它做你想做的事情，这是一个很好的特性。
不确定数据库的版本控制，但我假设您可以使用 TFS Source Safe 来实现这一点。
祝你好运！
我推荐以下工具（主要是因为我们正在使用它）：
我们每个人都在我们的本地机器上工作，并且有一个单独的构建服务器来监控 Subversion 存储库（使用 CruiseControl.NET）并在该服务器上构建最新版本。
我们使用“MSBuild 社区任务”将 Subversion 修订号嵌入到程序集中，以便我们可以将其显示给用户。
目前，我们设置中最大的“漏洞”在数据库和我们的自动化测试中。
目前我们都运行一个中央数据库服务器。理想情况下，您应该努力拥有一个在源代码控制下重新创建数据库的脚本。据我所知，每次构建服务器重建站点时，它也应该重建数据库。您还应该有一个脚本，它将在数据库中生成您想要的任何测试数据。
通过这样的数据库构建，您也可以在数据库的本地副本上工作。
您可能想看看Red Gate软件的 SQL 工具带（或其中的一部分）——我们使用 SQL 比较工具将模式部署到实时服务器，我对它们印象深刻。
祝你好运！
任何完美的 .NET 开发环境都会安装ReSharper的副本。我是最近的皈依者，我喜欢它。
我会为 Team Foundation Server 投票。然后，您可以将源代码控制、自动构建和（某种）错误跟踪都放在一个包中，它与 VS 2008 完美集成。不过，它的价格相当高。
我更喜欢 Visual Studio 2008 / Subversion / Trac / Anck and Tortoise / CruiseControl.NET (TeamCity / Bitten ) 设置。
我并不是说TFS不是一个伟大的产品，但我认为它“笨重”。我最近从 Trac / Subversion 解决方案切换到 TFS，我更喜欢第一个设置。有一些细节，但它们使它很好用。
例子：
小细节使它成为对我来说更好的工具。
我还说团队很小（也是 5 个开发人员），你需要一些时间来设置。我同意当您与更大的团队合作时，TFS 可能更可取。
在开发箱上
在服务器上
我对 IDE 和源代码控制的建议：
我最近改用 SourceGear Fortress。它便宜、快速且可靠。
我喜欢大型团队（>20 名开发人员）的 TFS。我刚刚开始接触 Subversion，所以我还没有什么要分享的，只是设置起来很容易。
然而，Trac 很难运行。不过，这是文档问题，而不是产品本身。
我的选择是：
更好的版本控制。
我会选择SourceGear Vault - 坚如磐石，像魅力一样工作，您的源存储在 SQL Server 数据库中 -> 可以轻松备份，并且不像 Visual SourceSafe 那样不稳定。
用于错误跟踪和文档的 Wiki 或其他系统。
根据我的个人经验：FogBugz是您最好的选择 - 简单、容易、快速掌握、很好地完成工作、工作，每个人都只是“得到它”，无需冗长且昂贵的适应/定制，也无需太多培训 - 工作正常：- )
简化的构建过程和日常构建（Visual Build？CruiseControl.NET？）
CruiseControl.NET 是一个很好的免费选择——如果你不介意花一点钱，我也会看看 FinalBuilder——无论是作为桌面应用程序还是服务器应用程序。
SQL Server 数据库的版本控制
--> 使用保险柜！以同样的方式工作。使用 Apex SQL Scripter 之类的出色工具或类似工具来创建和维护 SQL 以创建和更新数据库架构，并将这些 SQL 脚本放入 Vault。
升级到 Visual Studio 2005（或 2008）？
在 .NET 3.5 SP1 上使用 Visual Studio 2008 SP1 - 可靠且充满了出色的新生产力功能。
只是我的 0.02 美元
我们使用 SourceGear 的 Vault 进行版本控制，它对我们这个小团队来说效果很好。
对于项目/错误/支持跟踪，我们使用 AxoSoft 的 OnTime 2008。
我们还使用ScrewTurn Wiki 来记录程序和示例代码/最佳实践。
对于我们的构建过程，我们还没有完全自动化到日常过程中，因为我们通常不会那样工作。但是，对于 beta 和发布版本，我只是在手动更新版本号后使用 NAnt 为我进行完整的构建（我这样做是为了让我们的支持团队更好看版本号）。
并且绝对使用 Visual Studio 2008。2005 版本在大型 VB 项目中确实存在很多问题（至少对我们而言）。
我同意带有 SP1、SVN 的 VS2008（带有 Ankh 和 Tortoise）
查看sandcastle / docproject以生成文档。
CruiseControl 运行良好。
至于数据库的源代码控制，您可以使用 VS2008 中的数据库项目类型并使用 SVN（或您选择的其他源代码控制解决方案）将其保持在源代码控制之下。
我们将 Subversion 与Jira一起用于错误跟踪、项目管理、FishEye 和 Crucible用于源代码浏览和代码审查，并且效果非常好。
我们是一个由 12 名开发人员组成的团队，分布在各处。我们是FinalBuilder的长期用户，我们使用它来进行所有构建和自动化部署 - VB.NET 和 Visual Studio 2008 项目的混合，它对我们来说非常好。我们以 SQL Server 2005/2008 数据库为目标，并将数据库对象保存在源代码控制存储库中。大多数时候，我们将 Visual Studio 2008 数据库版与 Redgate 的工具结合使用，它对我们来说效果很好——尤其是管理更改脚本和其他东西。对我们来说，TFS 根本就行不通——尽管您的里程可能会有所不同。我们发现它太麻烦了，难以自定义工作流程，而且没有帮助工作流程，反而有碍事的坏倾向。
在带有 SP1 的 VS 2008 上非常肯定。我也强烈推荐：
我听说过很多关于 TFS 的好消息。但是，也有成本因素。您列出的工具可以很好地相互配合并且是免费的。
我要做的一个补充是用于 Subversion 客户端的TortoiseSVN 。纯粹主义者不喜欢它，但它与 Windows shell 的上下文菜单（右键单击）集成的事实使其非常易于使用。
对于 SVN 版本，请使用最近发布的 1.6 版本。此版本改进了分支和合并。
Trac is a great tool. Make sure to read up on TracWiki and TracLinks formatting rules for your SVN commit messages. Trac parses these messages so if you're commiting a fix for Ticket 123, adding '#123' to the SVN message allows Trac to link that commit (and all files associated with it) to the corresponding Trac tickets. This becomes especially usefull if and when you decide to move to delta releases.