Microsoft KB Archive/184354

= BUG: Working Folder for Subproject Not Inherited from Parent =

Article ID: 184354

Article Last Modified on 3/10/2005

-

APPLIES TO


 * Microsoft Visual SourceSafe 4.0 Standard Edition
 * Microsoft Visual SourceSafe 4.0 Standard Edition
 * Microsoft Visual SourceSafe 4.0a
 * Microsoft Visual SourceSafe 4.0a
 * Microsoft Visual SourceSafe 5.0 Standard Edition

-



This article was previously published under Q184354



SYMPTOMS
Subprojects are not inheriting the working folder setting from the parent project as expected.



CAUSE
You have overridden the normal behavior by explicitly setting the working folder for subproject(s). This results in a Dir= variable being set under the subproject section header in your Ss.ini file.



RESOLUTION
To restore the working folder inheritance, you need to edit the user's ..Vss\Users\\Ss.ini file and completely remove the Dir variable under the appropriate subproject section header.

For example, you may have something that looks similar to the following in your Ss.ini file:

[$/Project1] Dir(PC) = c:\Project1

;Setting the working folder then deleting it from the GUI leaves the Dir variable, but the value will be blank. [$/Project1/Sub1] Dir(PC) =

[$/Project1/Sub2] Dir(PC) = c:\temp

Default working folder propagation works again only after the "Dir(PC)" lines under each subproject section header are completely removed and the Ss.ini file saved.



STATUS
This behavior is by design.



MORE INFORMATION
When setting the working folder of a top-level Visual SourceSafe (VSS) project, by default all subprojects assume a working folder based on a mirror of the project's directory structure on disk.

For example, suppose you have the following project structure in VSS:

$/Project1

/Sub1 /SubofSub1 /Sub2

Setting the working folder for $/Project1 to C:\Project1 implicitly sets the working folder of the subprojects to C:\Project1\Sub1, C:\Project1\Sub1\SubofSub1 and C:\Project1\Sub1\Sub2, respectively.

If you explicitly set the working folder of a subproject, you are essentially telling VSS, "Don't assume a working folder for this subproject", which in some cases may be desired. VSS accomplishes this by adding the Dir variable under the subproject's header section in the Ss.ini file.

Steps to Reproduce Problem

 * 1) Create a project structure in VSS similar to the one above.
 * 2) Explicitly set the working folder for the subproject /Sub1 by highlighting it and choosing Set Working Folder from the File menu.
 * 3) Choose a folder and click OK.
 * 4) Now open the Set Working Folder dialog box again, and delete the chosen folder setting from the Name text box, then click OK. These steps remove the working folder for /Sub1 and create the Dir= in your Ss.ini file after you exit the VSS explorer.
 * 5) Now set the working folder for $/Project1. $/Project1/Sub1, or any of its subprojects, will not have its working folder set, but $/Project1 and $/Project1/Sub2 will have the working folder set.

NOTE: To maintain the default behavior of working folder inheritance, avoid setting the working folders for subprojects explicitly.

