I am in a situation where I have to take a bunch of Visual Studio projects which are scattered across the file system on a computer, and put them all in one self contained solution folder, under the same file in the file system. Are there any automated tools which are already built which can easily move projects which depend on one another into the same solution.

Basically I need to move projects into the solution directory, and alter references in the SLN file.

There are many projects like this, so doing it manually is a terrible waste of time.

I didn't develop the code, I have to maintain it.

I don't have a lot of time to learn to use a complex tool, but if there are good, simple tutorials that would be good.

Now I got a sln file only in a different directory, how could you possibly think that's what I wanted?

When you simply do the "add existing project" it makes a reference to the project in whatever folder it resides in. This allows for you to edit a project externally, that might shared across multiple solutions, and they all can get updated.

To get around this, move the project folder over to the new solution folder (I assume you know how the file structure is for a projects in relation to the solution).

cblock, the link I gave noted " relative base path " and more. It's far from automatic and something I wish Visual Studio did better.

The problem is that at work there is a large number of projects, distributed all over the file systems of multiple servers, and we basically have to try to implement a test server. It would make things much easier if the dependencies were all in one solution file so we could more easily handle theses applications. We are essentially having to clean up after a somewhat reckless programmer who has since moved on to another job. I don't want to disperrage, he knows the tech he uses, it's just now we have years of projects we have to maintain until we can build some more robust applications. They were running these projects with no test server, and that's the main hurdle we have to try to fix. Now in order to practice versioning, and copying these projects to another server it would be really convenient if there was a tool online which I could point at the head solution, and have it merge everything into one solution, in one main directory.

Is there any automated tool for this painful process?

cblock, the link I gave noted " relative base path " and more. It's far from automatic and something I wish Visual Studio did better.

I can take another look, but It doesn't look like what I need. Will it copy referenced solution "directories" (in the file system) to a specified directory under the main "solution"?

cblock. Nothing I found was automatic as in "take this project and move it to C:\projects and do what is needed to paths and copy all the stuff for me."

While the discussion I linked to helped me in the move I still needed to copy/paste the project folder over and then edit the sln.

-> Now there is something I must share. At no time did I decide to migrate the 100 projects. I do this only when needed so why migrate a dead project? There was this OCD programmer that tried but they don't work here anymore. Burned out pretty fast.

I have to ask, am I the only one who finds it weird the projects were scattered? Just seems weird you would build all the parts in different locations.

Personally I'd still say pull them onto one system, and merge all the folders manually. Yeah it's brutal, but it's not horrible, just a lot of copy/pasting (depending on the size). That way also you have everything in one centralized location, should an external source give you issues for some reason.

You know, now that I think of it, couldn't you theoretically write a pre-build event? Something like (and you might want to check this, my pre/post build events are okay, but I don't do them a lot)

xcopy /Y "$(ProjectDir)" "$(SolutionDir)"

I believe that would move the whole folder ... someone might want to double check that, but those are locations to directories. You might have to repoint the projects after the move, since they'll be looking in the original place, so there will be some redundency work, but at least it would pull them all to one solution location

I know that I think it is strange, I have never seen stuff scattered like this before, and apparently the programmer who was here last was using all sorts of different software versions for his databases too. It is going to be difficult to unravel this tangled web.

I found a link to a project on stack overflow, but unfortunately it doesn't go far enough. I think with some mods it could be a component to do what I want.


I ran the code, and apparently it simply creates a solution file that references the original locations of the solutions provided, no copy operations preformed. I think with some tweaks one could make a program that does what I need, with other components, for example a recursive file copy, and some other components. I can't devote much time to making an automated tool, but perhaps I could find some time...

That xcopy prebuild event is an interesting idea, we would need additional code to parse/update the sln file.

A note on rproffitt's post, if you were in this situation you would also be looking for an automated tool to preform this type of operation. I am in the position where I have to maintain a tangled mess of code where I literally don't know where all the files are, and I have to try to implement a test server. There is no test server here, due to the previous programmers practices everything is in production. We can't implement new code to do this overnight, and I have to try to keep plates spinning, possibly for years until we can get around to making new code that does what his code already does.

It isn't that unreasonable to make a tool for this, the main parts I see for it would be the following:

parse the sln file
select stuff that isn't in the root
copy the dependencies in
generate new sln file

The only problem I see with this approach would be paths actually in the source code, or sections/relative paths in the source code.

It is a good idea, the only problem is it's going to take to build anything. You'll need to learn the standard built for the sln file. YOu might be able to edit an existing one, with the projects currently referenced, and change their paths ... but it's going to take is the thing

Just a post of commiseration here. No version control, a rat's maze and possibly a decade of some system that grew by everyone saying "patch it and be quick about it."

I can't quite put this into the right words but I have seen management lose great folk over this. That is, the situation of no version control, a system spread over OSes, tools and more then the "next guy" is told they are not good enough because those prior were able to work with it without the big redo.

Sure, folk (programmers?) can make do but here you are with what looks like a production system ready for the next move. Let's hope you didn't call this system Jenga.

Probably should have called it jenga, I am the new guy, so it's not my fault... I just got here. So did my co-worker. It's funny you should mention our version control. Are you clavoyant? lol. We are implementing version control now, my co worker set it up. We hope to undo the mistakes of the past here...

I may have some time over weekends to persue this project idea of mine, no promises. We may just have to deal with stuff as it comes up for a while.

LOL I actually also mentioned a version control in an earlier post but then deleted it out (as I had a feeling you guys didn't ahve one with this last guy)

Yup, that's the case here. :)