This project has moved and is read-only. For the latest updates, please go here.

Long paths: Should guidance recommend shortening practices?

Jan 20, 2010 at 8:05 PM

I'm starting with the assumption that the 260 character path limitation remains in VS TFS 2010 (if not, please mention it, but ignore my concern).

I'm concerned that the guidance produces long path names for branched artifacts.


I've run into this problem primarily when importing third party or legacy source.

One example is the Patterns & Practices Enterprise Library. The source distribution for EntLib has fairly deep paths of its own and runs over the TFS 260 char server path limit pretty quickly when you start branching it with any significant nesting.

Some discussion about this and ways to avoid running into it during your Nth release cycle would be a great addition.

Jan 21, 2010 at 1:39 AM

I would start to address this problem by rasing awareness to this long-standing path/filename restriction. I suggest adopting a set of naming guidelines for naming files, folders, and branches. Such naming conventions would provide readable names with reasonable lengths. Try to minimize your folder hierarchy where possible. As you nest folders within folders, try not to repeat parent folder names in child folder names. Follow these same guidelines with respect to naming assemblies.

For example, I recently saw a customer with a folder / file path something similar to the following:

$/Gas Company Inc - Customer Service Dpt/Main/Src/GasCompany.CustomerServiceDpt/GasCompany.CustomerServiceDpt.DB/Schema Objects/Tables/Constraints/dbo.MeterReadingDetailCalculation.DF_MeterReadingDetailCalculation_IsMeterReadingActualOrEstimated.defconst.sql

As you can see from this example, "Gas Company" and/or "GasCompany" appears redundantly in this path three times, "Customer Service Dpt" and/or "CustomerServiceDpt" also appears three times, and "MeterReadingDetailCalculation" appears twice. It would seem to me that this file path/name could be reduced by almost 50% by using a good naming standard for abbreviations and/or eliminating redudundat name qualifiers:

$/Gas Co Inc - Cust Svc Dpt/Main/Src/GasCo.CustSvcDpt/DB/Schema Objects/Tables/Constraints/dbo.MtrRdgDtlCalc.DF_MtrRdgDtlCalc_IsMtrRdgActOrEst.defconst.sql

I would suggest that using reasonable branch names should not pose a problem when following our guidance, if the other components of the name are reasonably concise.

With respect to Enterprise Library, part of the problem has been the default installation location (in Program Files....). Many have addressed this problem by installing EntLib to a folder directly under the root of the local drive.

Bill Heys
VS Ranger