.net解决方案颠覆最佳实践？
关于如何设置 dotnet 项目的示例有很多，但似乎没有一个适合我们的情况。
我们拥有一种包含多个应用程序、多个依赖项的解决方案。 我们目前使用 SourceSafe，并计划转向 subversion，但发现很难以正确的方式组织我们的源代码。
示例解决方案
- 应用1
- 应用2
- BizObject
- 数据访问
- 自定义控件
依赖项
- BizObjects->DataAccess
- App1->自定义控件
- App1->BizObjects
- 应用程序1->数据访问
- App2->自定义控件
- App2->BizObjects
我们还有一个部署的配置管理系统（通过从数据库复制）取决于操作员正在工作的工作负载。 我们用版本标记应用程序“版本”，并向该版本添加多个文件依赖项。 请记住，我们现在采用的解决方案是尝试对旧的（Windows 3.1 开发的）解决方案进行创可贴，以便与 .NET 文件/依赖结构一起使用。
对于 App1，我们有 App1.exe、BizObjects.dll、DataAccess.dll 和 CustomControls.dll。 由于 BizObjects 引用 DataAccess，我们对 App2 具有相同的依赖关系集——但这是手动定义的。 我们没有适当的系统来识别依赖关系树。
“发布”的每个依赖项都是一个文件和版本 ID。 对于不同的工作负载，同一应用程序可以包含每个文件的不同版本。
- 我们到底哪里出了错？ 我们走错了吗？
- 我们如何构建 svn 源代码树来满足部署要求？
- 或
- 我们如何重组代码以更好地支持对我们的设置有意义的部署策略？
我们有一个陈旧且过度设计的解决方案来解决（看起来）一个相对简单的问题。 有人能引导我/我们走向正确的方向吗？
编辑：我读了这个问题并记住了我们还有代码必须经过的相同开发/测试/生产区域。
There are so many examples of how to set up your dotnet projects but none seemed to fit our situation.
We have one solution with multiple applications, multiple dependencies. We're on SourceSafe currently and are planning to move to subversion but are finding it difficult to organize our source the right way.
Example solution
- App1
- App2
- BizObjects
- DataAccess
- CustomControls
Dependencies
- BizObjects->DataAccess
- App1->CustomControls
- App1->BizObjects
- App1->DataAccess
- App2->CustomControls
- App2->BizObjects
We also have a configuration management system which deploys (via copy from the database) depending on which workload the operator is working. We mark an application "release" with a version and to that release, we add multiple file dependencies. Bear in mind the solution we have in place now is an attempt to band-aid the old (windows 3.1 developed) solution to work with .NET file/dependency structure.
In the case of App1, we have App1.exe, BizObjects.dll, DataAccess.dll, and CustomControls.dll.
We have the same set of dependencies for App2 due to BizObjects referencing DataAccess -- but this is defined manually. We don't have a system in place to identify the dependency tree.
Each of the dependencies for a "release" is a file and version id. And the same application could contain different versions of each file for a different workload.
- Where in the world have we gone wrong? Did we go wrong?
- How can we structure an svn source tree to accommodate the deployment requirements?
- or
- how can we restructure the code the better support a deployment strategy which makes sense for our setup?
We have an old and over-engineered solution to (it would seem) a relatively simple problem. Can anyone steer me/us in the right direction?
edit: I read this question and remembered we also have the same dev/test/prod areas which the code must move through.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
听起来您正在尝试使用源代码控制系统进行配置控制。
Subversion 我不是正确的选择，因为它实际上是针对源代码（ascii 文件）和构建依赖项，而不是可执行文件（二进制）和运行时依赖项。
我的猜测是你真的需要一个安装程序：
http://en.wikipedia.org/wiki/List_of_installation_software
或者也许只是一个要启动的脚本来自网络驱动器的正确配置。
Sounds like you're trying to do configuration control with a source code control system.
Subversion my not be the right choice, since it's really for source code (ascii files) and build dependencies, not executable files (binary) and run-time dependencies.
My guess is you really need an installer:
http://en.wikipedia.org/wiki/List_of_installation_software
Or maybe just a script to launch the correct configuration from a network drive.