I have been working on this project for a month. When I started, I didn't know anything about it and was inexperienced in .NET development. As a result, I created a project file structure that I do not like and will not work as the effort, and team, grows. This week is the week to get a code repository up and to create a testing/demo web server. That means it is also time to organize the files correctly.
What I want to do is simple. I want to rename my projects from their idiosyncratic starter names to, and I quote, UserInterface, DatabaseModel, TestProject. I want to move them out of their default directory and into one that is named after the project and is structured so that I can manage other things. The initial structure is to be, SourceCode (home to the three named above), SharedSoftware (home to nHibernate, mbUnit, etc), and ManagementFiles (home to stuff that arguably should not be in source control, especially Virtual Studio control files).
This would be, in my old world, about two hours work, and that would include reconfiguring Apache to point at the new directories. In my new world, I have just completed the chore and it has taken a full day, a good eight hours.
Among the reasons for this is the fact that, in true Microsoft fashion, they make no provisions for user flexibility. Specifically, they knit VS projects together with a "solution" file (.sln) that is hard-coded into the file system. It cannot be moved, nor can the code it manages. Worse, it insists on storing it in the middle of the source code. Anyone else that downloads the project is stuck with your preferences. It appears to combine the very worst combination of traits. Make catastrophic by the fact that Microsoft has provided no tool to edit this thing or to relocate the project. I have tried one million things. It is the dumbest thing I have ever heard.
But, I did devise a way to do it (including the relocation of the .slnfiles) and here is the story...
Reprise, the goals:
1) rename projects
2) create new directory structure (with .sln outside SourceCode)
3) put existing code into it
4) make it work correctly with Visual Studio
And an idiosyncracy: I prefer to divide the projects into separate solutions. The more usual way is to have one "solution" containing several projects. I prefer this because it allows me to have a separate, complete window for each solution. This is not possible for projects within a solution. Consequenlty, the three projects listed above, will each become a separate solution, each in its own directory. (Where needed, they refer to each other by reference.) This means that there is a .sln for each of them. My solution is the ManagementFiles directory inside of which I have directory, SolutionFiles, and inside that, one called, tqwhite. This is so that other people can store their own solution files without stomping on mine.
How to do it:
1) back up!!
2) create your new directory structure (inside ManagementFiles, create the SolutionFiles directory but not ones for each sub-project, VS will do that later)
3) distribute your source code into it; remove the .sln and .suo, keep the .csproj
4) open visual studio; if you moved, not copied, your source, when you select each solution, it will tell you it's lost and ask to remove it; say yes
For each sub-project:
5) sub-project, create a new project (for me, it's an ASP.NET
MVC Empty Project). It will ask where to put it. The correct answer is NOT "SourceCode", it goes in ManagementFiles, in the place where you want the .sln for this sub-project to reside.
6) choose the new project info, right-click and Remove it.
7) go to File->Add->Existing Project; choose the .csproj file for your source code (in the new sub-project directory); it will ask for a name, use the new one that you like
8) build the project
When you quit the project and return, you should see your new projects and they should work. If you're as lucky as me, one of the three will. I ended redoing it several times to get them all going.
Finally, when you move your stuff to SharedSoftware, you are going to have to reassign your projects' references.