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 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 for each file for a different workload.
- Where in the world have we gone wrong? Did we go wrong?
- How can we structure a svn source tree to accommodate the deployment requirements?
- or
- how can we re-structure 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.