Corey Roth [MVP]

I’ve been talking a lot about external lists lately as you may know.  They are so easy to create with SharePoint Designer, but you wouldn’t really deploy them to production that way would you?  Of course not!  We need a feature.  At first, you might think generating all of that CAML might be too difficult, but remember we can use the Save Site as Template page to generate a .wsp file for us.  Using this we can import it into Visual Studio and learn what CAML we need to use.

We’re going to start with the same external list from yesterday.  You can build your own using SharePoint Designer as described in my BCS post.

Once you are happy with your list, go to Site Settings –> Save Site as Template.  Fill in the fields and it will save a solution package in your solution gallery of your site collection.  Save the .wsp file to disk and we’re ready to begin.  Once you have your solution package, open Visual Studio 2010, create a new project, and use the Import SharePoint Solution Package project template.  You will be prompted for what site to use and where the package file is.  On the next step, you will be prompted for what you want to import.

The solution package has every site column, content type, page, list, etc, on the site so there is a lot to sift through.  However, the only thing we really need is the list instance in question (in my case Products).  You will want to unselect everything else as it will take forever to import if you don’t.

Quick Tip: There isn’t a select all button, so press Ctrl+A, and then unclick a checkbox to deselect everything.

On the next step you will get a warning about dependencies.  Go ahead and just say yes and your project will import.  Your project will likely have a bunch of stuff you don’t really care about.  All that you really need is what it is created in List Instances.  Your list instance might look something like this.

At this point, I created a new project because I want to keep things clean.  Create a new project and create a new List Definition.  At this point, you will have a schema file and two new elements files.  The elements.xml file with the list template can be deleted since I don’t want users creating new versions of this list.  Before we start digging into the CAML that is required to make an external list work, let’s go back and look at SharePoint Designer so we can remember what our application definition looked like.

The reason I show you this is because these values we’re going to see when we take a look at our elements.xml file.  Here is the file that came from the site export.

A couple of things to note here.  First, the TemplateType is 600.  We can only presume this is the list template id for an external list.  The other thing of note is the new DataSource element.  This was not in previous versions of SharePoint.  As you might notice here, these values correspond to what we see on the external content type.  This is what you will change should you decide to rename the entity in or change the LobSystemInstance name.  This XML is highly useable in our own feature, but I am going to remove some of the unnecessary attributes such as FeatureId and CustomSchema.  I’m also going to give it a new Title so that we know this is a different list.  Here is what my new elements.xml looks like.

Honestly, I think I can get rid of HyperLinkBaseUrl as well.  It doesn’t seem to matter though, I deployed it to a few other sites and it seems to work fine.  Now let’s take a look schema.xml.  It’s actually pretty small which is nice compared to the files we were used to in the past.

As you can see it’s pretty clean.  It again uses the Type of 600.  In the ContentTypes section, it does define a regular list item, but it doesn’t actually add any of the fields from the external list there.  The Fields element has a field defined for each field in my external content type.  As you can see there is nothing special about the way they are defined.  The only one of note is the BdcIdentity field which I assume is required to keep track of the ID that ties back to the BCS itself.  The View is surprisingly clean as well.  The XslLink and Method elements are new.  I assume we can use XslLink to customize how the view is rendered, but I didn’t actually see a main.xsl file generated in the solution package anywhere.  The Method element I can only assume corresponds to the name of the finder method Read List which we have seen above.  The rest is pretty simple.  It just has a FieldRef for each column in my external content type. 

I can pretty much use the Schema.xml file as is.  I did change the Title and Url attributes at the top but that is it.  At this point my new feature to deploy this is ready to go.  Here is what it looks like in Visual Studio.

Deploy your solution and have it activate your feature.  The new list won’t show up automatically in the navigation on the side, but it will be there.  Just go to the URL directly or view the lists on your site to get there.  Here it is on my new site.

As you can see it’s really not that hard to deploy an external list to another site properly using a feature.  Now, you might have noticed there are a few other elements.xml files generated when we did the site export.  One stores specific values in the property bag of the list.  This we did not want because we don’t really want to copy those internal properties.  The other deals with the forms of the list.  It uses the BinarySerializedWebPart which scares me a bit, so I haven’t messed with it much.  If you are just using default forms you don’t need to worry about it.  In a future post, I’ll try seeing if I can deploy some InfoPath forms along with the list, but I figured that deserves its own post.

Also, one other thing to note.  If you are deploying your external content type to another server, you can do that in the same manner as you did in SharePoint 2007.  Just export the application definition and import it on the new server.  You can also use the Export Application Model button in SharePoint designer on the External Content Types list.

I hope this helps when you look to move lists into production.  This technique of exporting and importing will also work with regular lists of course.  Just remember, friends don’t let friends deploy lists without a feature.