.NET解决方案颠覆最佳实践?

有很多关于如何设置您的网络项目的例子,但似乎没有一个适合我们的情况。

我们有一个具有多个应用程序和多个依赖项的解决方案。我们目前正在使用SourceSafe,并计划转移到Subversion,但发现很难以正确的方式组织我们的源代码。

• 示例解决方案

  • APP1
  • APP2
  • BiSbObjts
  • 数据访问
  • 定制控件

• 依赖关系

  • BizObjects--数据访问
  • 应用程序1->自定义控件
  • 应用程序1->BizObjects
  • 应用程序1->数据访问
  • 应用程序2->自定义控件
  • 应用程序2->BizObjects

我们还拥有一个配置管理系统,根据操作员正在工作的工作负载部署(通过从数据库复制)。我们用一个版本标记一个应用程序“版本”,在这个版本中,我们添加了多个文件依赖项。请记住,我们现有的解决方案是尝试使用旧的(Windows3.1开发的)解决方案来处理.NET文件/依赖结构。

对于app1,我们有app1.exe、bizobjects.dll、dataaccess.dll和customcontrols.dll。 由于BizObjects引用数据访问,我们对App2有相同的依赖集——但这是手动定义的。我们没有系统来识别依赖树。

“版本”的每个依赖项都是一个文件和版本ID。对于不同的工作负载,同一个应用程序可以包含每个文件的不同版本。

1. 我们到底哪里出错了?我们做错了吗?
2. 我们如何构造SVN源树以满足部署需求?
   • 或
3. 我们如何重组代码以更好地支持对我们的设置有意义的部署策略?

对于一个相对简单的问题,我们有一个陈旧的、设计过度的解决方案。有人能引导我/我们朝正确的方向前进吗?

编辑:我读 this 问题并记住,我们也有相同的dev/test/prod区域,代码必须通过这些区域。