The location for the Codeplex project is here.


After messing around a lot with the elements files to generate some pages I’ve created a small webpart that does all this stuff for you.

I’ve reused some code from this codeplex project and I’ve asked Stefan Stanev if I could re-use it. Also I’ve added some functionality.

The codeplex project of Stefan connects to SharePoint and if you go to the page via de program than you can right click and generate the elements.xml file.

Only the program doesn’t take into account connections between webparts. This and some other small adjustment I’ve added in my solution. So the elements file that you can generate via my webpart should be the most complete one representing the page.

I’ve shared the code with Stefan so that he can update his package, but I don’t know if he did this or not.

So the install is easy, it’s a WSP so install, deploy and put it on an webpart page (example called: admin.aspx).

How does it work? Continue reading

Today I noticed a good tool that you can use to create your own module elements files including extraction of the aspx file and automatic creation of the feature file as well.

This tool is created by Stefan stanev and can be found here.

But as I was using this I noticed that Views and Connections of connected webparts are not being extracted. So I’ve mailed Stefan and asked him if I could re-use some of his code and added some extra code so that the webpart connections are included.

The reason why I’m releasing this in a codeplex project as a webpart is because I believe that this could come in very handy for us SP developers. No longer creating the module elements file via code. Just click together what you want on a page and extract the module.

The codeplex project can be found here. Some styling still needs to be done.

First I’ve created a sandboxed solution, but this wasn’t possible because I use the SPLimitedWebPartManager . And as you can see, this is not usable in a sandboxed solution.

Ok, let’s start by explaining the module element.

In the elements file you can define multiple <Module> elements, all the possible attributes are listed below:

  1. includeFolders: (optional,string) – actually couldn’t find a single document/blog/page that describes what this attribute is for…

Karine (Bosch) found the answer:

Apparently when you have some files in your module element that need to be put in a subfolder of the library you use this attribute..

So you define includeFolders as ??-??

<Module Name=”PublishingLayoutsPreviewImages” Url=”_catalogs/masterpage” IncludeFolders=”??-??” Path=”” RootWebOnly=”TRUE”>
<File Url=”BlackVertical.png” Name=”Preview Images/BlackVertical.png” Type=”GhostableInLibrary”>

But this didn’t actually work for me.. so use at own risk Glimlach . Don’t really think you’ll ever need this.

Also somebody noted that it add the files to all child folders.. but this I don’t believe to be the behavior.

I’ll try to find it out in code how this part behaves, will get back to this one.

  1. HyperlinkBaseUrl: (optional,string) – This specifies the absolute url to be the base url of the hyperlinks… while I have set this and deployed to other sites (different from the base url) everything still worked, so really didn’t find any real value in this attribute
  2. List: (optional, integer) – Type of list where the files included in this module should be provisioned.

Let’s go to the onet.xml file where we can find an example on this one. As you can see the master page gallery has an typeId of 116. In the module node there is a defaultmasterpage example that has list defined to 116. So the defaultmasterpage is being deployed to this library.


  1. Name: (required, string) – contains the name of the file set. Nothing really special here.. just provide a name


  1. Path: (optional,string) – specifies the physical path of where the files are in the features folder. By default SharePoint expects the files to be in the same folder as the feature file. But you can also define the path attribute per file node
  2. RootWebOnly: (optional, boolean) – set to false by default, if you are installing the module only in the top level web site of the site collection than you must set this to true
  3. SetupPath: (optional,string) – specifies the physical path to a folder in the 14 hivetemplate that contains a file to include in the module.

Let’s say that you want viewpage.aspx in the pages directory under the template directory than your attribute should look like


  1. Url: (optional,string) – Specifies the virtual path of the folder in which to place the files of the module. This attribute is also used to provision a folder inside a list. If the Path is not specified, the value of this attribute will be used for the physical path also.