Hi,
We have a large codebase, consisting of around 40 visual studio "solutions" and 140 vs "projects". The 40 solutions correspond to 5 large "applications" consisting of various services, clients, database layers etc. About half of the projects are shared between 2 or more solutions.
At the moment, each solution references the individual projects, pulling in the source which is then compiled and built. We're trying to refactor things to be simpler and more maintainable, and at the moment it's a bit too complicated!
In previous roles (which were not using .net), we've managed to arrange things so that each component (which was virtually the same as a visual studio project) depended only on compiled components, and not source projects. The compiled components are built on a build machine and left in a read-only dropzone from where they can pulled in. The build machine iterated over the whole source tree, looking for components and trying to build them.
My question is:
+ is it possible to arrange this with a vb.net source tree? i.e. if i looked over the whole tree for project files, would I have enough information to build them? does a single project correspond to a single dll? are there any config settings that might be in the solution but not in the project and need to be compiled into the dll?
+ if it is feasible, i was imagining writing a script to remove the project references from the .vbproj file, and replace them with solid references to actual .dlls. is this likely to work?
Thanks for any thought!
Miles
We have a large codebase, consisting of around 40 visual studio "solutions" and 140 vs "projects". The 40 solutions correspond to 5 large "applications" consisting of various services, clients, database layers etc. About half of the projects are shared between 2 or more solutions.
At the moment, each solution references the individual projects, pulling in the source which is then compiled and built. We're trying to refactor things to be simpler and more maintainable, and at the moment it's a bit too complicated!
In previous roles (which were not using .net), we've managed to arrange things so that each component (which was virtually the same as a visual studio project) depended only on compiled components, and not source projects. The compiled components are built on a build machine and left in a read-only dropzone from where they can pulled in. The build machine iterated over the whole source tree, looking for components and trying to build them.
My question is:
+ is it possible to arrange this with a vb.net source tree? i.e. if i looked over the whole tree for project files, would I have enough information to build them? does a single project correspond to a single dll? are there any config settings that might be in the solution but not in the project and need to be compiled into the dll?
+ if it is feasible, i was imagining writing a script to remove the project references from the .vbproj file, and replace them with solid references to actual .dlls. is this likely to work?
Thanks for any thought!
Miles
