Linq to XML and Deleting Lists on Feature Deactivation

CoreyRoth — Thu, 24 Sep 2009 20:04:04 GMT

A few months ago, I discussed how to use LINQ to XML to parse your elements.xml file to delete any files that you may have deployed on feature activation. Today I have decided to reuse this concept to delete any lists that I have created when I deactivate a feature? Now you may ask, “why would I want to delete a list when a feature is deactivated? I’ll lose all of my data in that list!” My answer is: Yes, of course you will, but sometimes when building a feature to deploy a list(s), you want to delete the list each time before you deploy a new version of it. During development this is a huge time saver. Right now, I am working on a feature that deploys four document libraries. This means I have to manually delete each one. That is a huge waste of time, but what is nice is that we can reuse the concept above with LINQ to XML and delete lists instead.

The code is quite similar. Have a look. We first, write some code to get the path to the elements.xml file. This code snippet assumes, it is always named Elements.xml. Maybe in the future, I will have it look in the feature.xml file, get all of the ElementManifest definitions and then delete whatever it finds in each file. For now though, we assume, you can change the path as needed.

public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
{
    using (SPWeb currentSite = (SPWeb)properties.Feature.Parent)
    {
        string elementsPath = string.Format(@"{0}\FEATURES\{1}\Elements.xml", SPUtility.GetGenericSetupPath("Template"), properties.Definition.DisplayName);
        DeleteLists(currentSite, elementsPath);
    }
}

From here, it passes a reference to the current SPWeb and the path to the XML document. The path to the elements.xml file is used to populate an XDocument which we can then query with LINQ to XML.

private void DeleteLists(SPWeb currentSite, string elementsPath)
{
    try
    {
        XDocument elementsXml = XDocument.Load(elementsPath);
        XNamespace sharePointNamespace = "http://schemas.microsoft.com/sharepoint/";
 
        // get each URL to each list
        var listInstances = from module in elementsXml.Root.Elements(sharePointNamespace + "ListInstance")
                        select new
                        {
                            ListUrl = (module.Attributes("Url").Any()) ? module.Attribute("Url").Value : null,
                        };
 
        // iterate through each list and delete it
        foreach (var listInstance in listInstances)
        {
            try
            {
                SPList currentList = currentSite.GetList(string.Format("{0}/{1}", currentSite.Url, listInstance.ListUrl));
                currentList.Delete();
            }
            catch (System.IO.FileNotFoundException e)
            {
                // this exception is thrown if the list does not exist
            }
        }
 
        // update the site
        currentSite.Update();
    }
    catch
    {
    }
}

This code is quite similar to that used in my other post, however instead of looking for Module elements we are looking for ListInstance elements. It creates a list of those Urls to each list and iterates through them. For each list it finds, it deletes the list. I’ve written code in the past to manually delete lists, I create by name. That works fine, but the name of each list has to be maintained. Now, I just attach this to any feature I am working on and it deletes any list (or lists) that I throw at it. More than likely this isn’t something you want once you go to production, but it will save you a ton of time during development.

Using SharePoint with Enterprise Library 4.0 under Partial trust

CoreyRoth — Wed, 01 Oct 2008 15:52:55 GMT

Last year, I posted on how to use Enterprise Library 3.1 with SharePoint under partial trust. It was incredibly difficult to get it to work with SharePoint when using partial trust because none of the DLLs had the AllowPartiallyTrustedCallers attribute on them. This meant in order to get it to work, you had to add it to every AssemblyInfo.cs in the solution, sign it with your own strong name key, and then build and deploy it. It was a lot of effort.

Enterprise Library 4.0 has been out for a few months now, but I have yet to comment on it. I am pleased to report that with this new release, none of this overhead is required. All of the DLLs, have the AllowPartiallyTrustedCallers attribute which means all you have to do is reference the DLLs and assign appropriate permissions. I recommend putting Enterprise Library DLLs in a solution package which will make setting permissions easier. Last year's post should have most of the settings that you will need.

If you got turned off trying to implement Enterprise Library in the past with SharePoint, you might give it another try. With the APTCA change, it should make it much easier to use entlib for logging, exception handling, data access, or whatever.

How to get Enterprise Library working with SharePoint

C-Dog's .NET Tip of the Day — Wed, 05 Sep 2007 22:41:41 GMT

Once again, the most seemingly simple task with SharePoint has proved to be incredibly difficult. Continuing with my commitment to post the most information possible about SharePoint oddities, here is today's post. My goal today, I thought was simple...(read more)

Corey Roth [MVP] : Enterprise Library

Linq to XML and Deleting Lists on Feature Deactivation

Using SharePoint with Enterprise Library 4.0 under Partial trust

How to get Enterprise Library working with SharePoint