VS.NET mucking up working folder
Moderator: SourceGear
VS.NET mucking up working folder
Hi,
I've got a rather annoying problem with VS.NET mucking up my working folder for a rather complex project which has lots of projects shared between several solutions in quite a complex folder tree. Every so often, it makes a new set of folders within the old ones, which I then have to start using. I have ended up with my working folder for a part of the project looking like this...
Original Working Folder\Client\Client Side\Prog_Client\Client Side\Prog_Client\Client Side\Prog_Client
I'm a little worried that this keeps happening - is there any way of getting it to stop, because sooner or later I'll have to wipe out my working folder and start again (tried that - it didn't fix it permanently), as I'll hit the maximum subdirectory level for NTFS, and it is getting to be a pain to find stuff,
Thanks,
Martin
I've got a rather annoying problem with VS.NET mucking up my working folder for a rather complex project which has lots of projects shared between several solutions in quite a complex folder tree. Every so often, it makes a new set of folders within the old ones, which I then have to start using. I have ended up with my working folder for a part of the project looking like this...
Original Working Folder\Client\Client Side\Prog_Client\Client Side\Prog_Client\Client Side\Prog_Client
I'm a little worried that this keeps happening - is there any way of getting it to stop, because sooner or later I'll have to wipe out my working folder and start again (tried that - it didn't fix it permanently), as I'll hit the maximum subdirectory level for NTFS, and it is getting to be a pain to find stuff,
Thanks,
Martin
This usually means there is a reference somewhere in your project that is outside the root folder (described in http://support.sourcegear.com/viewtopic.php?t=552, which may be the kb article you were refering to).
I'm not sure of the best way to find the offending file or project, but one way might be to copy the entire structure somewhere else (to a different machine or different drive), and try to open it there (of course, without attempting to connect to source control), and see if it complains.
If this doesn't show anything, you could completely unbind that copied version from source control, and then try to add it to a repository in Vault that contains dummy data, and see if it gives you the c:\ working folder on the add. If it does, simply start removing projects from the solution until you get a good working folder, and then you've found the project that has the problem.
I'm not sure of the best way to find the offending file or project, but one way might be to copy the entire structure somewhere else (to a different machine or different drive), and try to open it there (of course, without attempting to connect to source control), and see if it complains.
If this doesn't show anything, you could completely unbind that copied version from source control, and then try to add it to a repository in Vault that contains dummy data, and see if it gives you the c:\ working folder on the add. If it does, simply start removing projects from the solution until you get a good working folder, and then you've found the project that has the problem.
Hmm, it's easy to find out which are the bad ones... It's simple: Every .sln should contain only projects which are at or below it's own subdirectoy. Then, each project file should contain files that are at or below the project file location. You can get the full path of a file from VS.NET: Just click on the file and the complete path will be displayed in the properties window pane.wizzard wrote:I forgot to mention that I had noticed the KB article on this, but there are about 15 projects in about 5 solutions and I'm not sure how to find the offending one(s).
gabriel magana-gonzalez
This is actually very annoying if you work the way I do - I have work projects and standard code libraries (which are also VS.NET projects) and I add the code library projects to the main work solutions. This means that the work solutions have to be in a folder above the one which contains the folders for my code library and the work projects folders.
eg...
Working Folder\
|--Solutions\
__|--a.sln
__|--b.sln
__|--c.sln
__|--...
__|--Work\
__|__|--a\...
__|__|--b\...
__|__|--c\...
__|__|--...
__|--Library\
__|__|--standard_class_lib1\...
__|__|--standard_class_lib2\...
__|__|--standard_class_lib3\...
__|__|--...
__|--Test\
_____|--Test_prog1\...
_____|--...
Not only that, but VS.NET insists on creating solutions in their own folder, so I keep having to go new blank solution, create it, close VS.NET, move it, wipe out the now blank folder, reopen it, add to vault, then add the projects, which I find rather messy. Anyone got a better way of doing it?
Martin
p.s. Excuse the mess, the underscores were the only way I could get it to display right.
eg...
Working Folder\
|--Solutions\
__|--a.sln
__|--b.sln
__|--c.sln
__|--...
__|--Work\
__|__|--a\...
__|__|--b\...
__|__|--c\...
__|__|--...
__|--Library\
__|__|--standard_class_lib1\...
__|__|--standard_class_lib2\...
__|__|--standard_class_lib3\...
__|__|--...
__|--Test\
_____|--Test_prog1\...
_____|--...
Not only that, but VS.NET insists on creating solutions in their own folder, so I keep having to go new blank solution, create it, close VS.NET, move it, wipe out the now blank folder, reopen it, add to vault, then add the projects, which I find rather messy. Anyone got a better way of doing it?
Martin
p.s. Excuse the mess, the underscores were the only way I could get it to display right.
I would be interested to hear if other folks other have good solutions for this.
My only contribution would be for you to read a KB article on sharing projects within the IDE at http://support.sourcegear.com/viewtopic.php?t=890. It can be quite a mess to set up, though.
My only contribution would be for you to read a KB article on sharing projects within the IDE at http://support.sourcegear.com/viewtopic.php?t=890. It can be quite a mess to set up, though.
Yeh, that's what I ended up doing. When I create a new solution (which is not often) I create it without adding it to source control. I get the paths straight first on the working folder, then as a last step, I add it to source control.wizzard wrote:This is actually very annoying if you work the way I do - I have work projects and standard code libraries (which are also VS.NET projects) and I add the code library projects to the main work solutions.
To me it's not a big pain, determining how to do it WAS a huge pain. But now things are running well.
What I wish existed, was a config flag somewhere to stop VS from "correcting" path mistakes by rearranging and copying files all over the place. If you don't pay attention and you fail to catch it right away, you might as well reach for your latest backup instead of trying to figure out which copy of every file you changed last.
gabriel magana-gonzalez