I have been called in to “clean up” and get started again in a .NET environment where the developers left quite a tangled mess. The developer is still available to me and he is/was able to pull up the solution on his machine, but when I attempt to use this is on my machine it creates a mess.
What I would like to do is to have an “Export Solution” that would pull all the various dependencies out and combine them in to a single Directory that reflects the solution layout.
If copying the files out is impossible (for exmaples, references to items in the GAC) is there any utility or way to get a full report of where everything actually is, the physical and virtual paths for both Debug and Release configurations. Also post-build tasks, etc. With a ton of projects of different types and various config screens, just manually trying to document it is possible, but has proved very error-prone, even for one very determine man.
I have tried just parsing the Solution file since its just text, but it doesn’t tell the whole story. Also part of that story is where the files are in Visual Source Safe, since when I have been able to pull together a working solution, VSS “corrects” me by randomly bring files in that then reference non-existing locations. It’s been a treat and VSS is a virus.
Any suggestions for extracting this from the only machine on the planet that will build this (and only in Release) so someone else could work on it?
Once I get it on my machine I am going to restructure it, but without a clear picture of how it “did” work that would be shooting in the dark.
I don’t know a way to export and I can’t guarantee anything b/c it sounds pretty messed up, but here’s what I would do. First, I would ask the guy to zip up his solution folder and send it to you. Then, I would create the same directory structure on my computer (so if he had the solution at s:\ … \solution\, I would do the same. Use subst to make the drive letter if necessary). Then, I would unzip the solution to the new directory root and open it with visual studio. Now is where the fun part begins. I would then try and re-do the bindings for VSS.
Once I had all that in place, I would ask the guy to tell me what 3rd party assemblies I need, if any. (Remember the GAC is not an issue as that is a run-time reference to assemblies and not a compile-time reference. Unless he did something crazy like reference physical GAC file locations. Ugh.) And ask him what the correct build order is. That is what are the projects that have no dependency on other projects.
Then, you need to try and build the lowest level projects one by one and correct build errors. Then move up one level to projects that depend on the projects you just compiled and so on until you have done the whole solution. Start by getting one project to build, then two, then three, until you have them all fixing the problems along the way.
Once you have a solution that builds, you can clean it up. Then, RUN don’t walk to replace VSS as your source repository.
GL. 🙂