This post reminded me of a system i came up w/ a while back to make managing vs.net projects a bit simpler from an administrative standpoint (indeed, exactly what is mentioned in the post). when you add projects to a .net solution, the path to that project (if it's non FPSE web apps and all others) is hardcoded into the .sln file as an absolute value, so if you were to change a drive letter, or decide you wanted to move all your projects to a shared drive, etc vs.net would have no idea where to look for those projects, and as shannon mentions you are not given a browse option when it can't find the project, so you would have to remove/re-add each project individually...a royal pain by any standard and certainly not very condusive to productivity. it's actually a pretty easy workaround, and if implemented early on, it can be a real timesaver down the line.
map a virtual drive to your VS projects folder, then in VS props change your Environment/Projects and Solutions location to this virtual drive letter. from this point forward no matter where you save your .sln file, it will reference projects using using the drive letter (the caveat here being you need to save all your project files in the same directory, which is probably the best thing to do anyways). sharing your VS projects file (with the appropriate perms) and then using a UNC name in VS Environment/Projects and Solutions property should provide the same functionality as well. i don't know how windows ACL GUIDS will affect the latter if you format, i am assuming the value is simply stored as a DWORD in the reg and VS won't do any ACL GUID checking. for web projects the process is very similar, simply change the Local Path prop in the IIS MMC console for the root web site dir to a UNC name (this will take some security tweaking in the sharing properties of your web directory on the file system, if you duplicate the settings on the security tab you will be ok, however you probably won't . VS.NET will then hardcode these values into SLN files (this applies to non FPSE web projects...if you use server extensions it won't matter, the value will be http://localhost/[project name]). if you format/change your working directory path, etc, all you need to do when you are done is redo the drive mappings/folder sharings, change the settings in VS.NET, and you should be good to go. i personally use drive mappings and haven't run into any issues when it comes to swapping out drives, so long as i've kept my project files nice and tidy.
hopefully this makes some sort of sense...if you actually walk through the steps you will see what the end result is, the actual location of your project files doesn't matter as long as you use some sort of pluggable name for the path (in this case UNC names, or virtual drive letters). cheers
Posted
Dec 21 2003, 07:37 PM
by
Jayson Knight