Maxime Bombardier - SharePoint Architecture & Development : Variations

Updating site parameters using the API may freeze the variation job

MaximeB — Sat, 26 Apr 2008 16:32:02 GMT

As you probably know if you read my blog, we like to automate as much as we can our WCM portal deployments. One of the thing we do is to update the Publishing Navigation to hide some sites/pages or simply re-order them correctly. Unfortunately, when you have variations and you want to automate this for all languages, you have to specify some kind of "sleep" time so that it waits for the Variation Timer Job to kick in and create the site in all labels.

Obviously, the sleep time period is guess work and is different on all servers (even on the same one!). During the first attempts, our sleep timer was rather low and we noticed that if we tried opening a site in a target variation/label while the variation process was doing its work, the process was simply stopping! I tried restarting the OWSTIMER service, rebooting the server, wait a day ... but no luck, it simply wasn't picking up again. The Timer Job definitions were still 'running' every minutes, they simply didn't check if there was any updates to propagate.

Unfortunately, so far, I haven't found a way to fix it and to be honest, we simply delayed running our updates on all labels to a later stage. While I did take a look at trying to 'kick start' the process, I didn't go very deep and if I have the issue again, I'll try Gary Lapointe's variation relationship fix (which is VERY interesting and practical even if you don't have the issue I outlined here). If that doesn't work, I'll go see if the relationship are created anyway but it's the Timer Job that cannot read them anymore. I'll update the post when I have the time to reproduce the error and debug it.

Maxime

Deployment lifecycle when using Site Definitions and Features (including post production day)

MaximeB — Sat, 23 Feb 2008 16:14:22 GMT

Summary

As you have noticed, I've changed my latest SharePoint focus to look at Site Definitions (and obviously Features but I played with them a lot prior to this). The reason for this is that I was looking at the "best" way to deploy artifacts for SharePoint WCM portals. While I had a very good working solution prior to me playing more with Site Definitions, I now think that I am ready to handle the task much better. This is also a follow-up to a previous article : http://blogs.msdn.com/maximeb/archive/2008/01/13/real-life-team-based-development-for-web-content-management-with-sharepoint-2007.aspx

The reason for this is that there is no single way to deploy SharePoint artifacts. Worst, once you deployed the first time, your original mechanism may not work anymore or if it does, it's probably not what you should use! What I'll attempt to do here is to define a few SharePoint artifacts that we deploy in a Web Content Management scenario for both production day and post production day, as well as the deployment lifecycle for the developers pre-production-day and post-production-day.

SharePoint artifacts we'll cover:

Master pages
Page Layouts
CSS / JavaScripts / Images (for the masterpages and layouts)
Site Columns & Site Content Types
Library content types association
Custom Lists
Event Handlers on libraries
Feature Receivers
Timer jobs

SharePoint topics discussed:

Site Definitions
Features
Variations
Feature Stapling
Timer Jobs
Content Deployment

Why Site Definitions?

The timing of me digging Site Definitions more and this post, http://www.andrewconnell.com/blog/archive/2008/02/15/You-dont-need-to-create-site-definitions.aspx, from Andrew Connell was interesting. First of all, he's right, you do not need to create a Site Definition all the time. However, there are also general guidelines. When you look at the Publishing portal that is available out of the box, it really looks like a good sample for reverse-engineering (and believe me, I opened it often to learn stuff!). How often have you kept the original "Press Releases" sub-site or used "Blueband" or any other master for your site? What Andrew mentions is that you should create your own minimal publishing site or you can take a look at this one here on CodePlex but I suggest you still take it apart with your requirements.

Also, I'm almost always in a multilingual scenario (i.e.: SharePoint Variations) and then Site Definitions takes its full meaning. Why? well the Variation mechanism is really just a system that provision sites. It is not a copy of the source site. When the variation timer job kicks in, it will detect a new site in the source variation. When it reads it, it takes the title, the description, the URL and the Site Template (i.e.: site definition). Then it simply does a standard Create Site... with those parameters. Once that is done, it will replicate only the publishing fields of the welcome page. Last, it will provision the other publishing pages the same way and replicate only the publishing fields on those pages. Note that any customization done manually at the source, beside publishing pages and fields, will NOT be brought to the other variations. That includes libraries undefined in the site definitions, documents or images, versioning settings, workflows, and everything else you see in the user interface that isn't a publishing field!

I think my last sentence was obvious enough that if you customize something at the source, you will customize it again at the destination. While there may be scenarios when you might want this, it'll be unusual and the solution is to use Site Definitions so that the provisioning brings as much as possible.

I'll finish this section with an example: today, if you have a Publishing site with the OOB site definition and that your welcome pages aren't "WelcomeLinks", what do you do? First of all, at the source, you created a new page with your layout. Then you updated the welcome page of your site to your new page and deleted the old "default.aspx". Now all your welcome pages are not "default.aspx" but it's no big deal. When you created a 2nd variation label, all the default.aspx/WelcomeLinks are back and they are the welcome pages of your sites in that variation!! So you again updated the welcome page and deleted the default.aspx. That's not very user friendly. Also, if you wanted to ended up renaming your custom page to "default.aspx", the variation mechanism would break when trying to provision the site since it's the name for the WelcomeLinks.

As you can see, Site Definitions becomes a must when using variations.

What defines a Site Definitions?

First of all, there is no golden rule for this but here's what I personally follow to determine if I use the same definition or a new one:

A different welcome page layout
I want to pre-provision a default set of web parts in a welcome page layout
(f) I want to associate specific content types to libraries
(f) I want to allow specific page layouts creation (i.e.: a "news" only section, a "product" only section, etc.)
(f) I want to add special Site Actions for some sites
(f) I want to have a special workflow for some sites
(f) I want to update library settings for some sites

Note that the items prefixed by "(f)" are items where the delivery mechanism is Features but they are associated in some site definitions.

Also, one note that will affect your site definition architecture are Feature Stapling. That functionality is one of the very practical mechanism to apply a feature to a site definition. Unfortunately, it's also "only that". What I mean is that if you have multiple sites with the same definition, it will apply the feature on all those sites. This is great inside a single Site Collection but when your SharePoint farm contains multiple site collections (possibly for different customers), you may not want to apply a feature to all of them. Unfortunately, I do not personally know of a better solution than to create your Site Definitions "per site collection" only (i.e.: in the naming). They will still likely use the same features though.

And really, when I design Site Definitions, I created a Feature that contains all the Features that I use for ALL sites. That way, my Site Definitions are very small and only contains the customization for that site. Also, I suggest taking a look at this tool to read your sites definitions : http://blogs.msdn.com/maximeb/archive/2008/02/16/site-definition-viewer-a-windows-net-2-0-tool-to-read-site-definition-and-features-configurations-version-0-1.aspx. I also created some CMD files to automate development of site definitions and they come in handy to maximize your time. I will post them soon.

Before taking a look at the SharePoint artifacts, I need to give you a bit of background on how we get the artifacts: We set up a MOSS server only for "web integrators". The Site Collections in there contains the files directly in the database edited through SharePoint Designer. We hooked up an event on the libraries that, when a check-in is done, it brings the file in a Team Foundation Server. Then, we have someone maintaining the build process and when he get the "go" from the web integrators, he builds the feature containing the files and that is sent to the developers for updates and eventually to production.

SharePoint artifact deployment - Master Pages - Page Layouts - CSS/JS/Images

1) Pre-production "day 1"

You should create a site-scoped Feature containing your master pages and other files (pages layouts and css/js/images). Take a look at the PublishingLayouts for ideas. When this feature is activated on a site collection, it will add the file in the libraries in a ghosted format which means that there are no customization on them. Note that if you ever unghost it at the destination, your feature will never update the file after.

2) Post-production "day 2+"

We'll have to define some sub-scenarios but first, let's start that, yes, you may be able to uninstall the feature and reinstall it while using the -force command but I do not recommend it. First, as I just mentioned, if you unghosted a file, it will not be updated. So if you plan on using this technique, make sure you test first. Also, I had some issues with BlobCache with CSS/JS/GIF/JPG but only when they were ghosted, never when unghosted.

Scenario #1 Updates to some/all the files

I would suggest creating an STSADM extension that update files defined in your Feature. This extension will unghost the file and it will act as your mechanism to deploy updates. What I use is a simple extension with an Xml input file that defines the files to update. This file simply grows over time since I only append to it. It gives me an added benefit with "change management" since it's not simply a build that picked up all files and sent it in the feature which may contain an update.

Scenario #2 New files

If you have new files, you probably have a "business reason" behind. For a new master pages or page layout, is it only for a new type of site (i.e.: defined in a site definition) or would you like to apply it automatically on some/all sites? That you have a new site definition or not, you are likely to have a new feature that brings the file. This feature may contain a Feature Receiver that will do some actions with those files such as :

Assigning the master page to some sites
Allowing the page layout to be created in some/all sites
If you have a new site definition, you may want to add it in the list of available web templates

Once you have your feature, you may want to create another one to staple the first feature with your site definition (some or all of them).

For new CSS/JS/images, they are probably used by a new page layout or master to being with so they will go in the same new feature.

3) Developers Pre/Post production day

During the initial development phase "pre-production day", developers should update their environment when they need it. Since I have everything in Team Foundation, I created special CMD/Bath files for developers that helps them clean/create a site definition with some sub-sites already pre-populated. This is enough for most cases. It's clean and fast and they are up and running quickly.

"Post-production day", the site definitions will not be updated (although they can be appended), nor the features, so they should run the same script that add files in the database and install the new features.

SharePoint artifact deployment - Site Columns and Site Content types + library association

1) Pre-production "day 1"

Feature is the best mechanism to bring columns and content types. Note that the feature has to be Site scoped so it will not bring the content types to a library unless you manually create a page through the GUI or that you use a content type association feature in your site definition. You can take a look at Andrew Connell's STSADM extension for a good sample of exporting your columns/content types.

2) Post-production "day 2+"

Well we learned the hard way, since the MSDN documentation wasn't available back then, that if you add a column to a content type (in a feature), a "reinstall" of the feature will only bring the new column at the Site Collection level and it will not be replicated down to each libraries using that content type. Fortunately, the user interface works great so if you do not have many columns to add, you may simply want to document the manual update.

But you know I like automation ... so yes, we are also fortunate with the API and it replicates down the change as well. An STSADM extension that adds column + associate it to a content type can be done easily so that it reads an Xml input file with all the updates since Day 1. When it runs, if the column's already there, it simply skips it and go check if the content type contains the association to it.

3) Developers Pre/Post production day

The same process will apply for developers. However, since the "STSADM extension" isn't created until Day 1, they may either recreate their site collection or manually add the column/content types when a change occurs. In my case, since creating a site definition is scripted, it goes very fast.

SharePoint artifact deployment - Custom lists

1) Pre-production "day 1"

A custom list is defined in a feature. The definition contains the columns and types. An instance of a list is defined in a Site Definition or through the user interface. You can also populate rows of data for an instance of a list defined in the Site Definition.

2) Post-production "day 2+"

That one is tricker, you can update and reinstall the feature. However, that will only affect new list creation. I personally haven't gotten the need to add columns and data to a list post-production but I would likely need another little STSADM extension to update it.

3) Developers Pre/Post production day

Same process as the content types, if it's only a feature, then reinstall it. If it's in the site definition, run the creation script.

SharePoint artifact deployment - Event Handlers, Feature Receivers, and Timer Jobs

1) Pre-production "day 1"

All of these are class items. You may want to run code for a specific event on a library, run code when a feature's activated, or run code through a timer job at a specific time. All of them are also originally brought through a feature.

2) Post-production "day 2+"

Now, this can be either very easy or much harder depending on how "politically correct" you want to be. Technically (or less politically correct), the classes are either in the BIN or the GAC, if you need to update the code, you can simply deploy them without touching anything in SharePoint (beside an application recycling or an IISRESET). That is, only if you kept the same assembly version.

Unfortunately, if you want to be more politically correct, you'd have to change the feature, since it contains the assembly version, and reinstall it but there are cases when it seems that some references are "ghosted" somewhere in a database so it may not work. If you want to be politically correct (and normally, we should) with assembly versions, I would strongly suggest doing tests.

3) Developers Pre/Post production day

For pre-production day, it's easy, the version isn't likely to change much so you are good to deploy the DLL and reset IIS/app pool. Post production day will depend on what you chose in scenario 2.

Content Deployment with all this

As long as your site definitions, features, and assemblies are all deployed at the destination, Content Deployment will work great with your artifacts. Sounds simple but even with all my run-ins with Content Deployment, it works good in that scenario.

Hope it helps a bit. I know it's a bit sad that there isn't a "single scenario" and I'm still using STSADM extensions to do some updates, but remember, most of the updates are doable from either SharePoint Designer or the web user interface. These 2 tools works good for the updates. Unfortunately, this version of the product doesn't seem to include the fact that field WCM deployments often have a more rigid and secure environment and SPD users aren't likely to play in production or even staging. That's when we, developers, want to automate the process and that's when we create STSADM extensions to fill the gap.

Maxime

Beware of SPWebProvisioningProvider when using Variations

MaximeB — Tue, 05 Feb 2008 20:22:20 GMT

I was doing some research lately on how to have a different "Approvers" group depending on business rule. To make it simple, the following statement had to be fulfilled:

Pages under subsite "/site1" have to be approved by group "Approvers1"
Pages under subsite "/site2" have to be approved by group "Approvers2"
and so on...
We are in a multilingual scenario (i.e.: Variations)

we also have custom site definitions for modifying the default welcome page to something else than WelcomeLinks as well as bringing our content types in the library. So the first thing we looked at was to use SPWebProvisioningProvider that allows to execute a class when provisioning a site. You can take a look at these URLs for more explanation on SPWebProvisioningProvider:

So basically, a site definition reside in the "onet.xml" file and you cannot define a class in that file. The WEBTEMP*.xml (defined in all "available languages", i.e.: 1033 folder for english) file is the configuration used by the "Create site" interface. This is where you specify your custom class for provisioning a web. The first thing your custom class does is to use ApplyWebTemplate() so that the web site is created with the correct template. Then I was simply modifying the "AssociationData" of the only workflow (Parallel Approval) to update its "Approvers" to my custom one depending on the URL.

So far, so good. Unfortunately, when you create this under a variation, it only works at the source. The reason for this is that the variation process is only a provisioning mechanism; furthermore, it's only provisioning based on the site definition, not any customization done after. That includes customization done through a SPWebProvisioningProvider. So basically, while the "onet.xml" file is called by the variation process, the "WEBTEMP*.xml" isn't.

What I ended up doing was to create a feature that contained the same code and added it to my site definition. If the sites are already deployed, you can look at at using Feature Stapling to do the same thing.

In my opinion, the SPWebProvisioningProvider should be a more accurate place to do this code as I want to customize another Feature through business logic. Of course, I could copy the ReviewWorkflow and create as many of them as I need plus as many Site Definitions for them, which might be okay for SharePoint, but wouldn't be a very reusable approach. I also find curious that we have a great customizable solution with the provider but it's simply not being called through the variation mechanism.

Maxime

You receive an error when you create a page, as a SharePoint Member, for the first time in a sub-site

MaximeB — Sat, 27 Oct 2007 15:19:11 GMT

We ran into a little issue the other day when using an account with only Member rights (yes yes, we are usually admins :)), we were creating a page for the first time in a sub-site and we were receiving a beautiful stack trace of nothingness. We refreshed the page and it was working fine, the page was added. With an account that's admin or owner, we didn't have that problem.

Now, we are creating the whole site structure programmatically through an STSADM and we are setting the AvailablePageLayouts collection per web application as to limit the type of pages authors can create for each sub-site. And I remembered an issue with Variations where the ContentTypes collection for each "target" variations weren't set correctly by the variation job. So I guessed right, we pre-populated the ContentTypes collection for each sub-site to contain a reference of all site content types that we accept for each sub-site and the error disappeared. Since we had the whole extension with an Xml input, it wasn't hard at that point to add "Available" ContentTypes to it.

It's quite possible that the GUI for updating AvailablePageLayouts does that, I didn't use Reflector on it nor did I check the ContentTypes collection when using the GUI, but my guess would be that the error's a bug since if you refresh the page creation, the content type is indeed added at that point and the 2nd creation will work.

Maxime

Small bug preventing from approving in French sites/variations (SharePoint)

MaximeB — Sun, 07 Oct 2007 19:27:50 GMT

One of my co-worker, Philippe Bédard, found a little bug last week that was preventing users to approve images in a French publishing web site. Basically, if you use the "View All Site" and navigate to a library that contains unapproved items, the contextual menu will show a "Approve" button. This button will take you to a page that contains a JavaScript to confirm your action.

Problem is, in French, the text (from a resource file) contains an apostrophe (') without encoding it for Javascript (\'). The Javascript simply breaks and the button doesn't fire. Luckily, you can approve from a different page through the Manage Content and Structure button and approve from there. The page that uses that resource is "_layouts/approve.aspx".

To fix the issue temporarily (until we have an official fix, otherwise, the resource file can be replaced by any fix/service pack), you can modify the wss.fr-fr.resx file that is contained in the 12 hive (12\Config\Resources) directory as well as any web site's App_GlobalResources directories. Look for the "approve_canleWorkflow_alert" (yes, typo there in the resource file, even better :)) and update the apostrophe. Here's what the resource file looks like :

Original version:

<value>Un flux de travail d'approbation du contenu est actuellement exécuté pour approuver cet élément. Si vous poursuivez cette opération, le flux de travail sera annulé.</value>

</data>

Fixed version:

<value>Un flux de travail d\'approbation du contenu est actuellement exécuté pour approuver cet élément. Si vous poursuivez cette opération, le flux de travail sera annulé.</value>

</data>

Thanks Philippe !

Maxime

My STSADM extension toolbox

MaximeB — Sat, 06 Oct 2007 21:34:14 GMT

Here's a listing of custom STSADM extensions myself and my coworkers have created. Feel free to ask questions regarding the namespaces for these. I'd like to thank those who contributed to this : Stéphane Perron, Louis Fournier, and Vincent Trépanier at Orckestra, an outstanding partner for SharePoint, Biztalk, and Commerce in Montreal; and a co-worker Philippe Bédard.

BaseStsAdmExtension

The basic class for all my extensions. It adds up default classes for a common output, verbose output switch, Url switch, and a wait switch to allow a developer to attach to the process.

ContentBuilder

Generates all columns, content types, page layouts, style sheets, site collection images, and master pages in a Feature. The "files" have to be exported (and we have another mechanism for that) in order to import them in another site. This was originally taken from http://andrewconnell.com/blog/articles/MossStsadmWcmCommands.aspx and then updated to fix a few issues and add more elements. You can also find information on Features here : http://msdn2.microsoft.com/en-us/library/ms460318.aspx and here http://www.codeproject.com/spoint/ExtendingSPS.asp.

PreloadWebSites

A simple extension that reads an input Xml file and hits all the specified Urls with HttpWebRequests. This helps loading specific content types & page layouts in the JIT after you ran the Warm up scripts.

PublishAllItems

An extension that will approve items in SharePoint. It has 2 main switches, one to approve "web integrators" libraries (Master pages, Style Library, Site Collection images); and one to approve "Pages" libraries starting a given path and downward. It will also cancel any workflow associated with the element's it's approving. You can also take a look at the one available at http://stsadm.blogspot.com/2007/08/stsadm-commands_09.html as it ended up being very similar to mine.

ResetMasterPages

This one I had to create to automate the master pages settings when using Content Deployment. There is a known bug where, when doing the first Full Content Deployment, the master page parameters aren't kept at the destination. This will bring them over.

ListBuilder

This will read an input Xml file and create custom lists with custom columns. It can also add Lookup site columns and add those columns to content types. This was done because we used Features to add content types but found out that a list was always recreated and used a different GUID. We couldn't provision Lookup columns to them and if we used a Feature to bring a list over, then the GUID was changing every time and causing issues with Content Deployment. It can also provision a BDC column in the list.

SiteBuilder

This extension will create a whole lot of things for a portal : sites with title/description, content pages with content (fields) values, set master pages, set available page layouts, set the content types per libraries (to fix a little bug), and set security (coming soon). It's great when you have features for the containers/artefacts and you want to add a default

AddLocalFile / DeleteLocalFile

We needed a little help to add and remove files other than through Features. Basically, we first had the issue when deploying updates to ItemStyles.xsl and other OOB files. This extension was deleting the OOB files from that web site and then applying the ones from our Feature (and we needed it in ItemStyles and couldn't have a custom file).

AddPublishingWorkflow/RemovePublishingWorkflow

This one is in development;I want to be able to add and remove the Publishing workflow for all sites so that we can switch between requiring a "publish" or an "approve" through the extension. We often want publishing only in development but an approval requirement for other environments; this extension would permit this.

There's also a bunch of custom extensions available by Gary Lapointe at the following address : http://stsadm.blogspot.com/2007/08/stsadm-commands_09.html.

I'll update this list with blog links when I create them and add new extensions.

Maxime

Listing all sites per variations - an STSADM extension solution

MaximeB — Tue, 25 Sep 2007 01:37:57 GMT

A little while ago, we ran into an issue with the Variation label creation process; it was ending successfully without creating everything. To make matters worst, it wasn't picking the missing sites/pages with the Synchronization Timer Job.

So it was very difficult to figure out what was missing in a particular variation except by browsing to each pages and figuring out if the page was missing. While we only had 150 sub-sites, it could create 10 or 140 of them.

For those interested, it seems that the issue is due to 3 things combined:

Memory leak in the variation creation process (scheduled to be fixed)
Potential memory leak when the farm is on a VMWare virtual environment
Not enough memory on the server :)

Now, while waiting to have more memory and a fix, we still had to create variations correctly. So far, we could only delete a variation and recreate it while hoping it would be done successfully. In order to assert that we had an incorrect variation label and to what extend, I ended up creating a small STSADM extension that was simply listing each sub-sites in an Xml format along with a counter on each node to mention how many sub-sites is under.

Essentially, create a class that implements ISPStsadmCommand and in the main class, call the EnumSites method passing the output file name & Url. Here's the Visual Basic.NET code excerpt :

        Private Function EnumSites(ByVal vOutputFile As String, ByVal vUrl As String) As String
            Dim output As String = String.Empty
            Dim siteMOSS As SPSite = Nothing
            Dim rootWeb As SPWeb = Nothing
            Dim publishingRootWeb As Publishing.PublishingWeb = Nothing
 
 
            Try
                siteMOSS = New SPSite(vUrl)
                rootWeb = siteMOSS.OpenWeb
                publishingRootWeb = PublishingWeb.GetPublishingWeb(rootWeb)
                Dim xmlDoc As New XmlDocument()
 
 
                Dim xmlDeclaration As XmlDeclaration = xmlDoc.CreateXmlDeclaration("1.0", "UTF-8", Nothing)
                xmlDoc.AppendChild(xmlDeclaration)
 
                Dim xmlRoot As XmlElement = xmlDoc.CreateElement("Variations")
 
 
 
                For Each web As PublishingWeb In publishingRootWeb.GetPublishingWebs
                    If web.Label IsNot Nothing Then
 
                        Dim variation As XmlElement = xmlDoc.CreateElement("Variation")
                        Dim attrSource As XmlAttribute = xmlDoc.CreateAttribute("source")
                        Dim attrName As XmlAttribute = xmlDoc.CreateAttribute("name")
                        Dim attrSiteCount As XmlAttribute = xmlDoc.CreateAttribute("numOfSubSites")
                        Dim numOfSubSites As Integer = 0
 
                        attrSource.Value = web.Label.IsSource.ToString
                        attrName.Value = web.Name
 
                        variation.Attributes.Append(attrName)
                        variation.Attributes.Append(attrSource)
 
                        output &= "Variation : " & web.Name & ", isSource=" & web.Label.IsSource.ToString & Environment.NewLine
                        numOfSubSites += EnumSites(xmlDoc, variation, web.Web.GetSubwebsForCurrentUser(), output)
 
                        attrSiteCount.Value = numOfSubSites.ToString
                        variation.Attributes.Append(attrSiteCount)
                        xmlRoot.AppendChild(variation)
                    End If
                Next
                xmlDoc.AppendChild(xmlRoot)
 
                output &= "Saving Xml output file ..."
                xmlDoc.Save(vOutputFile)
 
                Return output
            Catch ex As Exception
                output &= "Error : " & ex.Message & Environment.NewLine
            Finally
                If siteMOSS IsNot Nothing Then _
                    siteMOSS.Dispose()
                If rootWeb IsNot Nothing Then _
                    rootWeb.Dispose()
            End Try
 
            Return output
        End Function
 
        Private Function EnumSites( _
            ByVal vXmlDoc As XmlDocument, _
            ByVal vXmlParent As XmlElement, _
            ByVal vWebs As SPWebCollection, _
            ByRef rOutput As String _
        ) As Integer
            Dim numOfSubSites As Integer = 0
 
            Try
 
                For Each web As SPWeb In vWebs
                    numOfSubSites += 1
 
                    Dim site As XmlElement = vXmlDoc.CreateElement("Site")
                    Dim attrName As XmlAttribute = vXmlDoc.CreateAttribute("name")
                    Dim attrWelcomePage As XmlAttribute = vXmlDoc.CreateAttribute("welcomePage")
                    Dim attrSiteCount As XmlAttribute = vXmlDoc.CreateAttribute("numOfSubSites")
 
                    attrName.Value = web.Name
                    Try
                        attrWelcomePage.Value = PublishingWeb.GetPublishingWeb(web).DefaultPage.Name
                    Catch ex As Exception
                        attrWelcomePage.Value = "N/D --- " & ex.Message
                    End Try
 
                    site.Attributes.Append(attrName)
                    site.Attributes.Append(attrWelcomePage)
 
                    Dim numofSubSubSites As Integer = EnumSites(vXmlDoc, site, web.GetSubwebsForCurrentUser, rOutput)
                    numOfSubSites += numofSubSubSites
 
                    attrSiteCount.Value = numofSubSubSites.ToString
                    site.Attributes.Append(attrSiteCount)
 
                    vXmlParent.AppendChild(site)
                Next
            Catch ex As Exception
                rOutput &= "Error : " & ex.Message & Environment.NewLine
            End Try
 
            Return numOfSubSites
        End Function

You can essentially do the same for pages if you want to list them and do a compare with the source variation in order to list exactly what's missing, however, when we found out that the memory was the issue, we didn't extend this application so it's still in the "napkin format" :)

Maxime