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.