Developer Continuity
I have been hearing a lot in presentations about "Developer Continuity" in SharePoint 2010 Development but unfortunately I still don't think the tools are there still. A common scenario is for work to be done quickly in SharePoint Designer as a prototype, as let's face it, it's a lot quicker to do things in the Web UI/SharePoint Designer than in Visual Studio. A good example is adding a column to a list or adding a field to a content type.
At some stage you want to simply pull all your work into a Solution Package to deploy into a more controlled environment. I have found that this isn't that easy at all, I'm happy to be proved wrong here and also happy to help build a community tool that can do this. My recently published Whitepaper goes into more depth around the lifecycle of a SharePoint project.
So I tweeted the title of this post today after simply creating a Team Site in SharePoint 2010, going to "Save as Template" to create my WSP and then going into Visual Studio 2010 and selecting "Import WSP".
I know the guys in the Product Team may see this as a dig at them and I must admit my tweet is a little heated., I think the progress made in the tooling is fantastic. I just feel that they need to publicise the limitations of the tools along with its strengths. IT Bosses don't quote community members, they quote Microsoft slide decks from conferences and I can see a lot of "why is it taking so long" comments still like I mentioned a few years back on this blog.
What I got in return was not anywhere near what I expected and I'm questioning what "Import WSP" is actually for. There's not much out there in the community or on Microsoft content sites on this stuff as yet.
What it does do
Extracts artefacts from a WSP and puts it into the new structure of SharePoint Visual Studio Projects. It supports:
- Fields
- Content Types
- List Instances
- Modules (kind of)
- Properties
- Workflow associations
- Event Receivers instances
- Web Templates
What it does badly
Unintuitive wizard
- The "Select items to import" picks up everything…very confusing if all you want is a page layout or a single Content Type.
- It doesn't seem clever enough to realise the files are out of the box un-customised files e.g. they'll be there anyway if you deploy this to a site, so why add the noise to the project?
Poor Naming
Considering the naming is so poor I was expecting some tutorials on how to use this thing at RTM time. So far I've seen no-one talking about this and I suspect it is because it is so hard to use and describe how and when you would use it.
Strips out stuff
Some of the files that it exported dropped stuff for example it strips out data in WebPartZones that are there in SharePoint Designer 2010 files when you look at them in the Virtual File System within Page Layouts.
Exporting a Workflow
The workflows exported from SharePoint Designer 2010 also have a similar unintuitive naming, you'll spend a fair amount of time trying to change the naming before you even begin trying to modify the outputted code.
What it doesn't do
Module files
I had some Content Artefacts (css and xsl files) that I'm using in Content Query Web Parts and it doesn't save this as part of WSP.
Save as Site Template
This is actually blocked in Publishing sites…definitely something to be aware of.
List Items
I ticked it to include content but it does not seem to do any List Item content e.g. <RowData> in <ListInstance>.
What can we do?
Well in 2007 we had Solution Generator that came with VSeWSS 1.2 (1.3 CTP still isn't released) and also another open source project which I assisted on with Rich Finn called SPSource. Both reverse engineer instances of Artefacts (Content or Solution) and allow you to use them in Visual Studio. I had hoped that we would not need SPSource in SharePoint 2010 due to tooling improvements, but I believe that this will be required to do the kind of scenarios I mention above.
I will continue to investigate this and blog about it in the near future.