Hi,
I have a solution that used to contain one SharePoint 2010 project. The project is named along the following lines:
<Company>.<Product>.SharePoint - let's call it Project1 for future reference. It contains a number of features which have been named according to their purpose, some are reasonably long and the paths fairly deep. As far as I am concerned we are using sensible namespaces and these reflect our company policy of "doing things properly".
I first encountered the following error message when packaging the aforementioned SharePoint project into a wsp:
"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."
I went through a great deal of pain in trying to rename the project, shorten feature names and namespaces etc... until I got it working. I then went about gradually renaming everything until eventually I had what I started with, and it all worked. So I was none the wiser...not ideal, but I needed to get on and had tight delivery timelines.
Recently we wanted to add another SharePoint project so that we could move some of our core functinality out into a separate SharePoint solution - e.g. custom workflow error logging. So we created another project in Visual Studio called:
<Company>.<Product>.SharePoint.<Subsystem> - let's call it Project2 for future reference
And this is when the error has come back and bitten me! The scenario is now as follows:
1. project1 packages and deploys successfully with long feature names and deep paths.
2. project2 does not package and has no features in it at all. The project2 name is 13 characters longer than project1
I am convinced this is a bug with Visual Studio and/or the Package MSBuild target. Why? Let me explain my findings so far:
1. By doing the following I can get project2 to package
· In Visual Studio 2010 show all files of project2, delete the obj, bin, pkg, pkgobj folders.
· Clean the solution
· Shut down Visual Studio 2010
· Open Visual Studio 2010
· Rebuild the solution
· Package the project2
· et voila the package is generated!
This demonstrates that the package error message is in fact inaccurate and that it can create the package, it just needs a little help, since Visual Studio seems to no longer be hanging onto something.
Clearly this is fine for a small time project, but try doing this in an environment where we use Continuous Integration, Unit Testing and automatic deployment of SharePoint solutions on a Build Server using automated builds.
2. I have created another project3 which has a ludicrously long name, this packages fine and also has no features contained within it.
3. I have looked at the length of the path under the pkg folder for project1 and it is large in comparison to the one that is generated for project2, that is when it does successfully package using the method outlined in 1. above. This is strange since project1 packages and project2 does not.
4. If I attempt to add project2 to my command line build using MSBuild then it fails to package and when I then open up Visual Studio and attempt to package project2 from the Visual Studio UI then it fails with the path too long error message, until I go through the steps outlined in 1. above to get it to package.
5. DebugView shows nothing useful during the build and packaging of the project.
6. The error seems to occur inCreateSharePointProjectService target called at line 365 ofMicrosoft.VisualStudio.SharePoint.targetsCurrently I am at a loss to work out why this is happening? My next task is to delete project2 completely and recreate it and introduce it into my Visual Studio solution.
Microsoft, can you confirm whether this is a known issue and whether others have encountered this issue? Is it resolved in a hotfix?
Anybody else, can you confirm whether you have come up with a solution to this issue? When I mean a solution I mean one that does not mean that I have to rename my namespaces, project etc... and is actually workable in a meaningful Visual Studio solution.