03b_PackageSolutions.bat failure

Jan 12, 2010 at 4:48 PM

I'm seeing the following error in the setup:

------ Deploy started: Project: Contoso.PartnerPortal.Collaboration.OrderException, Configuration: Debug Any CPU ------
------ Packaging started ------
------ Validate solution and resolve deployment conflict(s) ------
Validating solution ...
Operation completed successfully.
------ Generate solution file and setup batch file ------
Creating solution ...
Error: System.IO.PathTooLongException
The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.

Log file written to: C:\Documents and Settings\Administrator\Application Data\Microsoft\VSeWSS 1.3\VSeWSS1.3.log

That log file contains the following:

2010/01/12 11:31:54    Error
Error: System.IO.PathTooLongException
System.IO.PathTooLongException: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
   at System.IO.Directory.InternalCreateDirectory(String fullPath, String path, DirectorySecurity dirSecurity)

   at System.IO.Directory.CreateDirectory(String path, DirectorySecurity directorySecurity)
   at Microsoft.SharePoint.Tools.SharePointSolutions.SolutionElementMaker.Make(ISolutionElement element, String path)
   at Microsoft.SharePoint.Tools.SharePointSolutions.FeatureElementMaker.Make(ISolutionElement element, String path)
   at Microsoft.SharePoint.Tools.SharePointSolutions.FeatureMaker.Make(ISolutionElement element, String path)
   at Microsoft.SharePoint.Tools.SharePointSolutions.SolutionMaker.Make(ISolutionElement element, String path)
   at Microsoft.SharePoint.Tools.SharePointSolutions.SolutionCreator.MakeSolution(ISolution solution, String path)
   at Microsoft.SharePoint.Tools.SharePointSolutions.SolutionDeployer.Deploy()

What can be done to get past this error?  The environment is Windows Server 2003 SP2, MOSS 2007 SP2, SQL Server 2005 SP3, all patched through December 2009. 

Jan 12, 2010 at 8:08 PM

Hi fmorriso,

looks like your extracted path is too long. can you extract zip into c:\ drive( ex: c:\spgdrop) and try again.




Jan 13, 2010 at 2:29 AM

I had to make several changes to successfully install:

1. I copied everything from my original location of C:\download\microsoft\SharePointContosoRI\ to C:\spg\, which eliminated the PathTooLongException.

2. I had to edit C:\spg\Setup\PartnerPortal\SupportingFiles\00_Parameters.bat to remove the "REM" in front of the following line:

REM =======================================================================================================
REM =====START SET path if user try to run individual Files ===============================================
 IF "%SourceFolder%"=="" GOTO SetSourceFolder
  GOTO AfterSourceFolder
  Set SourceFolder=%~dp0%..\..\..\
  Set subfolder=%~dp0%

REM =======================================================================================================
REM ==== set SQLserverName for SQL Server Instance to install ContosoFBAdb (for FBA roles and members) ====

 set SQLserverName=%computername%

 if exist "%ProgramFiles%\Microsoft Office Servers\12.0\Data"  goto OFFICESERVERS  (THIS IS BAD ASSUMPTION #1)
 if exist "%ProgramFiles(X86)%\Microsoft Office Servers\12.0\Data"  goto OFFICESERVERS (THIS IS BAD ASSUMPTION #2)
 goto END_SQLserverName  
  set SQLserverName=%computername%\OFFICESERVERS

 REM set SQLserverName=%computername%\OFFICESERVERS
 REM set SQLserverName=%computername%\SQLExpress
 REM set SQLserverName=%computername%  <----- remove the REM from the beginning of this line to overcome BAD ASSUMPTIONS #1 and #2 above

The reason I had to make the above change it that I normally install SQL Server 2005 Enterprise Edition and then SQL Server 2005 SP3 afterwards. 

Your install erroneously assumes that if there is a Data directory underneath the 12 hive that the default SQL Server instance name is OFFICESERVERS, which is not true in my case (and I suspect 98% of the rest of the world).

Failure to make the above changes will cause the initial install to not work and even worse, will make any attempt to uninstall fail when it comes time to uninstall the various SQL Server databases because the uninstall routines will erroneously attempt to connect to the non-existant default SQL Server instance named OFFICESERVERS.

Jan 13, 2010 at 1:54 PM

Hi fmorriso,

Thanks for your feedback, setup shows information & wait for user confirmation before install, it shows all details like sqlserver instance name, login user details, site details.

we will try to  findout best solution to see what sql server installed,so that it will be useful to user.







Jan 13, 2010 at 2:15 PM
Edited Jan 13, 2010 at 2:16 PM
  1. Please consider having an XML "response" file that we would change rather than having to change multiple .bat or .cmd files (i.e., practice Separation of Concerns design pattern).
  2. Please use PowerShell instead of .bat and .cmd files.  Adding one more prerequisite won't make that much of a difference.  Besides, everyone should be learning PowerShell now in order to be ready for SharePoint 2010 down the road.
  3. Add a section to the prerequisites that includes instructions on how to use the SQL Server (2005) Surface Area Configuration Tool to verify that the userid running various SQL-related functions has all the proper rights.  This is especially true since SQL Server 2005 Service Pack 1 was released, so it is just one more thing that should be double-checked.  I forgot to do that for my situation and it helped overcome a bad error during the installation.
  4. Add a section on how to overcome the bug of "Trial version has expired" after applying SharePoint 2007 Service Pack 2 (just point to the link where the information is found, don't bother repeating all of it).  In my situation, I chose to simply use Central Administration to reenter the license key and perform an IISRESET.
  5. Mention what to do if you previously installed Silverlight 3, including what to do if you installed the Silverlight 3 Tools for Visual Studio 2008 SP1 and the Silverlight 3.0 SDK.  In my case, to complete the install, I had to go back and download the Silverlight 2.0 SDK and install it side-by-side with the existing Silverlight 3.0 SDK, which appears to have worked from what limited post-install verification that I have performed.  Having both of them installed may come back to bite me in the rear later on, but for now, it seems to allow me to at least install everything.