Corey Roth [MVP] : SharePoint 2010, SP2010 Beta, Feature

Deploying an External List via Feature using CAML #sp2010

CoreyRoth — Thu, 25 Feb 2010 19:33:13 GMT

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.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <ListInstance FeatureId="{00bfea71-9549-43f8-b978-e47e54a10600}" TemplateType="600" Title="Products" 
                Description="" Url="Lists/Products" CustomSchema="Files\Lists\Products\Schema.xml" 
                HyperlinkBaseUrl="http://sp2010/Test" RootWebOnly="FALSE" 
                xmlns="http://schemas.microsoft.com/sharepoint/">
    <DataSource>
      <Property Name="Entity" Value="Products" />
      <Property Name="EntityNamespace" Value="http://sp2010/test" />
      <Property Name="LobSystemInstance" Value="bcs_test" />
      <Property Name="SpecificFinder" Value="Read Item" />
    </DataSource>
  </ListInstance>
</Elements>

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.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <ListInstance TemplateType="600" Title="Products - Deployed by Feature" Description="" 
                Url="Lists/ProductsDeployedByFeature" HyperlinkBaseUrl="http://sp2010/Test" 
                RootWebOnly="FALSE" xmlns="http://schemas.microsoft.com/sharepoint/">
    <DataSource>
      <Property Name="Entity" Value="Products" />
      <Property Name="EntityNamespace" Value="http://sp2010/test" />
      <Property Name="LobSystemInstance" Value="bcs_test" />
      <Property Name="SpecificFinder" Value="Read Item" />
    </DataSource>
  </ListInstance>
</Elements>

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.

<?xml version="1.0" encoding="utf-8"?>
<List Title="Products" Direction="none" Url="Lists/Products" BaseType="0" Type="600" 
      FolderCreation="FALSE" DisableAttachments="TRUE" Catalog="FALSE" RootWebOnly="FALSE" 
      SendToLocation="|" ImageUrl="/_layouts/images/itgen.gif" xmlns:ows="Microsoft SharePoint" 
      xmlns:spctf="http://schemas.microsoft.com/sharepoint/v3/contenttype/forms" 
      xmlns="http://schemas.microsoft.com/sharepoint/">
  <MetaData>
    <ContentTypes>
      <ContentType ID="0x01" Name="Item" Group="List Content Types" Description="Create a new list item." FeatureId="{695b6570-a48b-4a8e-8ea5-26ea7fc1d162}">
        <Folder TargetName="Item" />
        <FieldRefs>
          <FieldRef ID="{c042a256-787d-4a6f-8a8a-cf6ab767f12d}" Name="ContentType" />
          <FieldRef ID="{fa564e0f-0c70-4ab9-b863-0177e6ddd247}" Name="Title" Required="TRUE" ShowInNewForm="TRUE" ShowInEditForm="TRUE" />
        </FieldRefs>
        <XmlDocuments>
          <XmlDocument NamespaceURI="http://schemas.microsoft.com/sharepoint/v3/contenttype/forms">
            <FormTemplates xmlns="http://schemas.microsoft.com/sharepoint/v3/contenttype/forms">
              <Display>ListForm</Display>
              <Edit>ListForm</Edit>
              <New>ListForm</New>
            </FormTemplates>
          </XmlDocument>
        </XmlDocuments>
      </ContentType>
    </ContentTypes>
    <Fields>
      <Field DisplayName="BDC Identity" Hidden="FALSE" Name="BdcIdentity" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="BdcIdentity" Type="Text" />
      <Field DisplayName="Name" Hidden="FALSE" Name="Name" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="Name" Type="Text" />
      <Field DisplayName="Id" Hidden="FALSE" Name="Id" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="Id" Type="Integer" />
      <Field DisplayName="Color" Hidden="FALSE" Name="Color" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="Color" Type="Text" />
      <Field DisplayName="Description" Hidden="FALSE" Name="Description" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="Description" Type="Text" />
      <Field DisplayName="Price" Hidden="FALSE" Name="Price" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="Price" Type="Decimal" />
    </Fields>
    <Forms />
    <Views>
      <View DisplayName="Products Read List" DefaultView="TRUE" BaseViewID="1" Type="HTML" MobileView="TRUE" MobileDefaultView="TRUE" ImageUrl="/_layouts/images/generic.png" XslLink="main.xsl" WebPartZoneID="Main" WebPartOrder="1" Url="Read List.aspx" SetupPath="pages\viewpage.aspx">
        <XslLink>main.xsl</XslLink>
        <Method Name="Read List" />
        <Query>
          <OrderBy>
            <FieldRef Name="Name" />
          </OrderBy>
        </Query>
        <ViewFields>
          <FieldRef Name="Name" ListItemMenu="TRUE" LinkToItem="TRUE" />
          <FieldRef Name="Id" />
          <FieldRef Name="Color" />
          <FieldRef Name="Description" />
          <FieldRef Name="Price" />
        </ViewFields>
        <RowLimit Paged="TRUE">30</RowLimit>
        <Aggregations Value="Off" />
      </View>
    </Views>
  </MetaData>
</List>

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.

Intro to SharePoint 2010 Development: How to Build and Deploy a Web Part

CoreyRoth — Mon, 15 Feb 2010 20:17:41 GMT

If you are already familiar with SharePoint 2010, you already know how easy it is to build and deploy a web part now. However, this post is for those that don’t keep up with SharePoint as some of us do and may not realize how the development experience has improved so much. My post How to Build and Deploy a Web Part is by far the most popular post on DotNetMafia.com. I wanted to make today’s post just as a point to show you how much less work is involved in deploying a web part. I am going to group this post into sections in a similar manner as I did the post for the WSS3 post.

Environment

There can be entire talks about what the best way to develop is now, but we’ll start with the simplest. Although you can install SharePoint on Windows 7 and directly develop on it, most people are going to say stick with a virtual machine and run Windows Server 2008 R2. It’s certainly simpler to get all of the prerequisites installed if you stick with Windows Server. The benefits to developing directly on a machine with SharePoint on it are so great now that I would recommend against remote debugging (although you still can). The SharePoint Root (or the 12 hive as you called it) is now the 14 hive and is located at the predictable path below.

C:\Program Files\Common Files\microsoft shared\Web Server Extensions\14

Coding the Web Part

Here is where things start to change. Instead of creating a class library and adding references to the SharePoint DLLs, we simply use one of the new included SharePoint project templates as you can see here.

Start by using the Empty SharePoint Project template. Also make sure you have it set to .NET Framework 3.5 as SharePoint does not run under .NET Framework 4.0 (don’t get me started). You’ll notice you have many different project templates to choose from. Most of these can also be used once you create an empty project. On the next dialogue, pick farm solution. I’ll go into the difference between sandboxed and farm solutions, but more than likely you are going to use farm solutions every time. You also need to specify the URL to your server. You can change that if you want but the default value will probably work for you in this case.

This gives us a solution that looks like this.

Now we are ready to build our new web part. If you bring up the add new item context menu, you will see a number of choices for the types of new SharePoint Project Items (SPIs) that you can create. We’re going to choose Web Part in this case.

What is the Visual Web Part you ask? That’s just a user control which relates directly to my second most popular post on How to Deploy a User Control. Now we’re finally ready to add some code. We’re just going to take our code from the WSS3 post and use it here.

using System;
using System.ComponentModel;
using System.Runtime.InteropServices;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using Microsoft.SharePoint;
using Microsoft.SharePoint.WebControls;
 
namespace SharePointProject1.TestWebPart
{
    [ToolboxItemAttribute(false)]
    public class TestWebPart : WebPart
    {
        public TestWebPart()
        {
        }
 
        protected override void CreateChildControls()
        {
            base.CreateChildControls();
            Controls.Add(new Label() { Text = "My Test SharePoint 2010 Web Part (Hello World)!" });
        }
 
        protected override void RenderContents(HtmlTextWriter writer)
        {
            base.RenderContents(writer);
        }
    }
}

The only line of code I added here was the line to add the label and set its text. Everything else came from the template.

Describing the Web Part

In my WSS3 post, this is where I talked about building a .webpart file. Well, you don’t need to worry about that any more as Visual Studio creates it for you. Here is what solution explorer looks like after you add your first web part.

As you can see the .webpart file is already there as well as an elements.xml file for a feature to deploy the web part. The WSS3 post went on to talk about all of the things you need to know about building a feature. This is still good stuff to know, but its already taken care of for you. If you want to edit the basic feature information, just open it up in solution explorer and you get a nice new interface that looks like this.

I’m not going to waste space showing you the insides of the files it creates for you. Just know it creates them for you and it saves you a ton of time.

Deploying via Solution Package

In my WSS3 post, I explained how to create a cab.ddf and manifest.xml file. Well guest what? That is taken care of for you now as well. The Package.package file in the solution explorer provides another nice editor which allows you to choose with files go into the package. You don’t have to keep track of a thing any more, it just builds the package and takes care of it for you.

At this point, Visual Studio has created the .webpart file, the feature, and the solution package. However, we still need to deploy it and if we could debug it that would be even cooler right? Take a look at our new options in the Build menu.

We can build and rebuild just like any other project, but notice the options for Deploy, Package, and Retract. Those are all SharePoint functions. In this case, I want to deploy my solution. Choosing deploy, we see the following in the output window.

------ Build started: Project: SharePointProject1, Configuration: Debug Any CPU ------
SharePointProject1 -> C:\Code\SharePointProject1\bin\Debug\SharePointProject1.dll
Successfully created package at: C:\Code\SharePointProject1\bin\Debug\SharePointProject1.wsp
------ Deploy started: Project: SharePointProject1, Configuration: Debug Any CPU ------
Active Deployment Configuration: Default
Run Pre-Deployment Command:
Skipping deployment step because a pre-deployment command is not specified.
Recycle IIS Application Pool:
Recycling IIS application pool 'SharePoint - 80'...
Retract Solution:
Skipping package retraction because no matching package on the server was found.
Add Solution:
Adding solution 'SharePointProject1.wsp'...
Deploying solution 'SharePointProject1.wsp'...
Activate Features:
Activating feature 'Feature1' ...
Run Post-Deployment Command:
Skipping deployment step because a post-deployment command is not specified.
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========
========== Deploy: 1 succeeded, 0 failed, 0 skipped ==========

From inspecting the text of the log, you can see that Visual Studio compiled, created a package, reset my Application Pool, Added the Solution, Deployed the Solution, and activated the feature. Let’s check SharePoint and see if it’s really there.

Checking the web part gallery, we see our .webpart file. Let’s add it to a page and see how it looks. Edit any page and use add a web part and you will see the new interface for choosing a web part. It puts it in the Custom group by default.

One you hit and add finish editing, we see the web part working correctly.

You have to admit this is quite a bit easier than deploying a web part in SharePoint 3. What if you want to debug though? No problem. Just set a breakpoint and choose debug from the build menu like you would any other type of project.

As I mentioned earlier, if you are familiar with SharePoint 2010, this is nothing new to you. However, my point today is for those who shied away from SharePoint in the past because the development experience was far from optimal. Try it for yourself and you will see how easy it is to get up and running with your code. Even with pictures this post is half the size of the WSS3 post. That’s because it really is just that easy. I really think Visual Studio 2010 will open the way for a new round of SharePoint developers. Try it out today.

Using the PropertyBag element to assign properties to Items in SharePoint 2010

CoreyRoth — Thu, 11 Feb 2010 21:43:28 GMT

When the NDA dropped, I mentioned how you could use the new PropertyBag element in a feature to write values into the property bag of a site. I already thought that was going to be incredibly useful, but it turns out the power of this new element is even greater than I first realized. At the time I noticed that the PropertyBag element had a Url attribute but I didn’t understand what it was used for at the time. Now I do. As I mentioned yesterday, I have been experimenting with exporting sites as .wsp files and I discovered that you can use this to write to properties of an existing list item. Take a look at the following example, that I grabbed from the file it generated when exporting my site. This applies properties to default.master.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <PropertyBag Url="_catalogs/masterpage/default.master" ParentType="File" RootWebOnly="FALSE" HyperlinkBaseUrl="http://sp2010/Test" xmlns="http://schemas.microsoft.com/sharepoint/">
    <Property Name="vti_charset" Value="utf-8" />
    <Property Name="vti_candeleteversion" Value="true" />
    <Property Name="vti_modifiedby" Value="SHAREPOINT\system" />
    <Property Name="vti_cachedneedsrewrite" Value="false" />
    <Property Name="vti_level" Value="1" />
    <Property Name="vti_rtag" Value="rt:7CDE768C-FCE1-46E8-9165-FDA564419D9A@00000000002" />
    <Property Name="vti_cachedbodystyle" Value="&lt;body scroll=&quot;yes&quot; onload=&quot;BLOCKED SCRIPTif (typeof(_spBodyOnLoadWrapper) != 'undefined') _spBodyOnLoadWrapper();&quot;&gt;" />
    <Property Name="vti_title" Value="&lt;asp:ContentPlaceHolder id=&quot;PlaceHolderPageTitle&quot; runat=&quot;server&quot;/&gt;" />
    <Property Name="UIVersion" Value="3" />
    <Property Name="vti_parserversion" Value="14.0.0.4536" />
    <Property Name="vti_cachedhastheme" Value="false" />
    <Property Name="vti_foldersubfolderitemcount" Value="0" />
    <Property Name="vti_hasdefaultcontent" Value="true" />
    <Property Name="vti_setuppathversion" Value="4" />
    <Property Name="vti_metainfoversion" Value="2" />
    <Property Name="vti_canmaybeedit" Value="true" />
    <Property Name="vti_generator" Value="Microsoft SharePoint" />
    <Property Name="vti_etag" Value="&quot;{7CDE768C-FCE1-46E8-9165-FDA564419D9A},2&quot;" />
    <Property Name="vti_cachedtitle" Value="&lt;asp:ContentPlaceHolder id=&quot;PlaceHolderPageTitle&quot; runat=&quot;server&quot;/&gt;" />
    <Property Name="vti_contentversion" Value="0" />
    <Property Name="vti_progid" Value="SharePoint.WebPartPage.Document" />
    <Property Name="vti_timelastmodified" Value="2010-02-10T16:12:34Z" />
    <Property Name="vti_sourcecontrolversion" Value="V1.0" />
    <Property Name="vti_timecreated" Value="2010-02-10T16:12:34Z" />
    <Property Name="vti_folderitemcount" Value="0" />
    <Property Name="vti_docstoretype" Value="0" />
    <Property Name="ContentTypeId" Value="0x01010500CE60EDAC92E8C942BFB82AF8AFC4A5F4" />
    <Property Name="vti_filesize" Value="29039" />
    <Property Name="vti_sourcecontrolcookie" Value="fp_internal" />
    <Property Name="vti_author" Value="SHAREPOINT\system" />
    <Property Name="vti_setuppath" Value="global\default.master" />
    <Property Name="vti_metatags" Value="GENERATOR Microsoft\ SharePoint progid SharePoint.WebPartPage.Document HTTP-EQUIV=Content-Type text/html;\ charset=utf-8 HTTP-EQUIV=Expires 0" />
    <Property Name="vti_replid" Value="rid:{7CDE768C-FCE1-46E8-9165-FDA564419D9A}" />
    <Property Name="vti_docstoreversion" Value="2" />
    <Property Name="vti_cachedcustomprops" Value="vti_title" />
  </PropertyBag>
</Elements>

As you can see the relative URL of the file is specified along with a separate attribute indicating the base URL it came from. You also need to specify something for ParentType. For now I know that you can specify File or Folder there (although I am guessing it might take Item or something like that).

Now for the most part all of these properties listed above are internal properties that you would never care about setting, but as you guessed you can specify your own properties as well. The export site as template functionality does its best to export everything it can and that includes internal properties as well. This is pretty interesting feature and I think it could remove the need to write a lot of code in my future. @SPKyle might still want to write code to store properties on list items, but I will take a pass. :)

Feature Versioning and Upgrades in SharePoint 2010

CoreyRoth — Mon, 04 Jan 2010 21:30:48 GMT

One new feature in SharePoint 2010 is the ability to version and upgrade features. I haven’t seen a lot of people talking about it yet, so I thought I would take a few minutes to talk about it today. It’s an interesting new feature and I’ll be curious to see how much people use it and when. The versioning aspect of features is interesting, but specifically what we’ll be talking about today are what kinds of things we can do when we perform a feature upgrade. Unfortunately, by the time you read all of this, it will probably leave you with more questions than you started with. You will probably be asking yourself a lot of questions like “well, what happens when I upgrade a feature and it has X in it?”.

The first thing to know is that SharePoint 2010 makes use of the Version attribute on the Feature element now. We can then use this version to execute code or do various things in an element manifest. This is also an easy way to add a new site column to a content type which we’ll talk about in a bit. It all starts with the UpgradeActions element in your feature.xml. It takes a ReceiverAssembly and ReceiverClass attribute just like the Feature element takes. Here is what it would look like.

<UpgradeActions ReceiverAssembly="MyFeatureReceiver, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3e1b35c83d6e53f4"
  ReceiverClass="MyFeatureReceiver.MyFeatureReceiver">

If you’re not going to be executing custom upgrade action code, you can leave that part out the assembly. You can then optionally add a VersionRange that takes BeginVersion and EndVersion attributes. You can specify multiple VersionRange elements to handle upgrades across multiple versions with one file. You can then specify what you want to occur on the feature upgrade.

<VersionRange BeginVersion="1.0.0.0" EndVersion="1.9.9.9">

One of the most common things you can do is to specify a separate element manifest file which deploys various things to SharePoint when the solution is upgraded. This file will have the same syntax as any other elements.xml file you have used. Here is what that would look like.

<ApplyElementManifests>
  <ElementManifest Location="WebPart1\UpgradeManifest.xml"/>
</ApplyElementManifests>

Another thing you can do is rename a file. So if you deployed a file called default.aspx and now you want to be called default2.aspx, you can have your upgrade make the change. I have no idea if it would actually update anything that references the file. I would guess not, but it’s there to try out if you ever need it.

<MapFile FromPath="OldFilename.aspx" ToPath="NewFilename.aspx" />

One thing, that is pretty interesting is the ability to add new site columns to an existing content type. The syntax is pretty similar and it will even push down changes to content types that inherit from it. Just specify the ContentTypeId, FieldId, and whether or not you want it to PushDown.

<AddContentTypeField ContentTypeId="0x010100F15ADB2FA333AD49848E7E01BC79C9750202"
                     FieldId="{b63c6371-f774-451d-b4fb-5679625fafd5}"
                     PushDown="TRUE" />

The last thing to mention is that, you can execute custom code when a feature is upgrading. If you have some complex upgrade logic this is the way to go. It works by overriding the FeatureUpgrading event handling method. It passes the UpgradeActionName and an IDictionary of parameters. I’m not going to go into what the code looks like on a feature upgrade today, but I will cover it in a future post soon. Here is what a complete UpgradeActions element might look like in your feature.xml.

<UpgradeActions ReceiverAssembly="MyFeatureReceiver, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3e1b35c83d6e53f4"
  ReceiverClass="MyFeatureReceiver.MyFeatureReceiver">
  <VersionRange BeginVersion="1.0.0.0" EndVersion="1.9.9.9">
    <ApplyElementManifests>
      <ElementManifest Location="WebPart1\UpgradeManifest.xml"/>
    </ApplyElementManifests>
    <AddContentTypeField ContentTypeId="0x010100F15ADB2FA333AD49848E7E01BC79C9750202"
                         FieldId="{b63c6371-f774-451d-b4fb-5679625fafd5}"
                         PushDown="TRUE" />
    <CustomUpgradeAction Name="MyCustomUpgradeAction">
      <Parameters>
        <Parameter Name="Parameter1">Some Value</Parameter>
        <Parameter Name="Parameter2">Some Other Value</Parameter>
      </Parameters>
    </CustomUpgradeAction>
    <MapFile FromPath="OldFilename.aspx" ToPath="NewFilename.aspx" />
  </VersionRange>
</UpgradeActions>

I’ll be really curious to see how and if people use feature upgrades. It definitely seems like it can be useful, but I don’t know if I will want to have my feature broken out into a bunch of different manifest files when I start having lots of upgrades.

Writing to the Property Bag using CAML in SP2010

CoreyRoth — Tue, 20 Oct 2009 15:51:32 GMT

There are a number of feature improvements in SharePoint 2010. They have made many changes which allow you to do more with features when they are activated or upgraded. One of the new features it the ability to write to the property bag. To do this we just make use of the new PropertyBag element in your elements.xml file. Here is what a file might look like that writes to the property bag. As usual, I’ll point out that features or syntax could change.

<Elements xmnlns="http://schemas.microsoft.com/sharepoint/">
  <PropertyBag ParentType="Web">
    <Property Name="MyCustomProperty1" Value="some value" />
    <Property Name="MyCustomProperty2" Value="4" />
  </PropertyBag>
</Elements>

I will point out that whatever type you initialize the property with, it will become semi-permanent. Currently, this applies for integers and date/time. If you try to save another type in an existing property later, you will end up with a null value being stored. This will save me some time in the future as I have had to write code to do this in the past.