The unwritten work-arounds for using the SharePoint Solution Generator
So I have been working on a demonstration lately with the new SharePoint Solution Generator which is an included tool in the Windows SharePoint Services Extensions for Visual Studio. The promise of this tool is that you can point it at an existing site or list and get an equivalent SharePoint list or site definition. Notice I did not use the word "template". Templates are easy to create and that feature has been available even in SharePoint 2003. The difference is that a definition is maintained on the file system of the front-end web servers. Templates are just deltas of changes that have been made from the original definition. The importance of definitions is that they provide the possibility of changing and having the change ripple through existing instances. So this tool has quite the attraction as developers have been converting templates into definitions by hand for some time. In addition to this tool, this package includes new VS.NET project templates. You can get it at: https://www.microsoft.com/downloads/details.aspx?FamilyID=19f21e5e-b715-4f0c-b959-8c6dcbdc1057\&DisplayLang=en.
Now there are many posts out there on the net that will walk you through how to use it. But very few of them will make this point. This tool must be run on the SharePoint server and it makes one HUGE assumption. The assumption is that you have a web application that is accessible from the url https://YOURCOMPUTERNAME. Now I know that most dev systems are setup that way. Mine is not. The only web app I have has a fully qualified name of portal.sample.com. So to get this tool to even run. You must first change the value of the COMPUTERNAME environment variable from a command window before launching the tool (from the same window). Something like:
Set COMPUTERNAME=portal.sample.com
and then start the tool from its executable.
This is quite tolerable, but unfortunately the VS.NET project templates make the same assumption. So to get them all to work as expected, you must also start VS.NET from the same command window after using the COMPUTERNAME variable.
Lastly, the capture site definition feature doesn't like to play nice with complicated sites or ones that have MOSS features enabled. I have often found myself setting up the site and then de-activating all of the features except Team Collaboration to get it to capture. Web part connections also seem to throw it off a bit. I haven't explored all the variables here, but thought I would at least pass on the advice.