如何建立dotnet项目的例子很多，但似乎没有一个适合我们的情况。

我们有一个具有多个应用程序，多个依赖项的解决方案。我们目前正在使用SourceSafe，并计划进行颠覆，但发现很难以正确的方式组织我们的资源。

• 应用2
• 商业对象
• 数据访问
• 自定义控件
• App1-> CustomControls
• App1-> BizObjects
• App1->数据访问
• App2-> CustomControls
• App2-> BizObjects

我们还有一个配置管理系统，该系统可以根据操作员的工作负荷进行部署(通过从数据库中进行复制)。我们使用版本标记应用程序"版本"，并向该版本添加多个文件依赖项。请记住，我们现在使用的解决方案是尝试对旧的(Windows 3.1开发的)解决方案进行创可贴以与.NET文件/依赖关系结构一起使用。

对于App1，我们有App1.exe，BizObjects.dll，DataAccess.dll和CustomControls.dll。
由于BizObjects引用了DataAccess，因此App2具有相同的依赖关系集-但这是手动定义的。我们没有合适的系统来识别依赖关系树。

"发行版"的每个依赖项都是文件和版本ID。并且同一应用程序可以针对不同的工作负载包含每个文件的不同版本。

• 我们在哪里错了？我们做错了吗？
• 我们如何重组代码以更好地支持对我们的设置有意义的部署策略？

对于一个相对简单的问题，我们有一个过时的，过分设计的解决方案。谁能引导我/我们朝正确的方向前进？

编辑：我读了这个问题，并记得我们也有相同的dev / test / prod区域，代码必须通过这些区域。

解决方案

回答

这是一个可能相关的问题。链接文字。

回答

听起来我们正在尝试使用源代码控制系统进行配置控制。

Subversion并不是正确的选择，因为它实际上是针对源代码(ascii文件)和构建依赖项，而不是可执行文件(二进制)和运行时依赖项。

我的猜测是我们确实需要安装程序：
http://en.wikipedia.org/wiki/List_of_installation_software

或者也许只是一个脚本，用于从网络驱动器启动正确的配置。