.net解决方案颠覆最佳实践?
-
08-06-2019 - |
题
关于如何设置 dotnet 项目的示例有很多,但似乎没有一个适合我们的情况。
我们拥有一种包含多个应用程序、多个依赖项的解决方案。我们目前使用 SourceSafe,并计划转向 subversion,但发现很难以正确的方式组织我们的源代码。
示例解决方案
- 应用程序1
- 应用程序2
- 业务对象
- 数据存取
- 自定义控件
依赖关系
- BizObjects->数据访问
- App1->自定义控件
- 应用程序1->BizObjects
- 应用程序1->数据访问
- App2->自定义控件
- 应用程序2->BizObjects
我们还有一个配置管理系统,它根据操作员正在处理的工作负载进行部署(通过数据库的副本)。我们用版本标记应用程序“版本”,并向该版本添加多个文件依赖项。请记住,我们现在采用的解决方案是尝试对旧的(Windows 3.1 开发的)解决方案进行创可贴,以便与 .NET 文件/依赖结构一起使用。
对于 App1,我们有 App1.exe、BizObjects.dll、DataAccess.dll 和 CustomControls.dll。由于 BizObjects 引用 DataAccess,我们对 App2 具有相同的依赖关系集——但这是手动定义的。我们没有适当的系统来识别依赖关系树。
“发布”的每个依赖项都是一个文件和版本 ID。对于不同的工作负载,同一应用程序可以包含每个文件的不同版本。
- 我们到底哪里出了错?我们走错了吗?
- 我们如何构建 svn 源代码树来满足部署要求?
- 或者
- 我们如何重组代码以更好地支持对我们的设置有意义的部署策略?
我们有一个陈旧且过度设计的解决方案来解决(看起来)一个相对简单的问题。有人能引导我/我们走向正确的方向吗?
编辑:我读 这 问题并记住我们也有代码必须经过的相同的开发/测试/生产区域。
解决方案
这是一个可能相关的问题。 链接文本.
其他提示
听起来您正在尝试使用源代码控制系统进行配置控制。
Subversion 我不是正确的选择,因为它实际上是针对源代码(ascii 文件)和构建依赖项,而不是可执行文件(二进制)和运行时依赖项。
我的猜测是你真的需要一个安装程序:http://en.wikipedia.org/wiki/List_of_installation_software
或者可能只是一个从网络驱动器启动正确配置的脚本。