Corey Roth [MVP] : Visual Studio 2010

Slides from my SharePoint 2010 Development Talk at SharePoint Saturday Houston 2011

CoreyRoth — Mon, 16 May 2011 19:34:37 GMT

Sorry, I’ve been slacking. I’m a full week behind on posting my slides from SharePoint Saturday Houston 2011. This SharePoint Saturday was certainly unforgettable and I had a great time both attending and speaking. I presented my Beginning SharePoint 2010 Development talk to a room packed full of people. The turnout for the event was great. Many thanks again to the master mind @Victor_Chat and all of the great people H-SPUG for putting the event on. I had a great time. I’ve uploaded the slide deck to SlideShare for your reference. I’ve also provided links to my relevant blog posts which will help get you started with SharePoint 2010 development. If you have additional questions, feel free to ask.

Beginning SharePoint 2010 Development for ASP.NET Developers Slide Deck

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

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

Office 365 How to: Build and Deploy a Web Part with SharePoint Online

Follow me on twitter @coreyroth.

Office 365 How to: Build and Deploy a Web Part with SharePoint Online

CoreyRoth — Fri, 01 Apr 2011 16:08:28 GMT

You know by now that the cloud is hot and Microsoft says “we’re all in”. That being said, there has never been a better time to push all of those chips forward and jump on the bandwagon. It’s time to get some experience with SharePoint Online / Office 365. I know most people don’t have access to the Office 365 beta yet, but when it opens up, you should sign up for the public beta and start getting familiar with it. If you haven’t seen SharePoint Online yet, check our my previous article which gives a quick tour of it. I plan to write more about SharePoint Online in the future, so I figured the best place to start is with an introductory development article on building and deploying a web part. My past series on building and deploying web parts to 2010 and 2007 are still the most popular articles on DotNetMafia.com. Let’s take what we learned there and see how we deploy web parts to the cloud.

Before we get started, let’s reiterate what we’re working with. With Office 365, your development scenario involves sandboxed solutions. As you know, these solutions are deployed to the site collection level and offer a restricted subset of the SharePoint API. If you are already confortable working with sandboxed solutions, you are in great shape to begin SharePoint Online development.

What does the development environment look like? Well, you know that SharePoint 2010 VM you already have? You’re looking at it. Just like Azure, SharePoint Online development also used the “Over the fence” development methodology. Meaning, you develop your code locally and then throw it over the fence and hope it works. This may sound bad, but it’s really not a big deal and the Azure people have been doing it for a while. AppFabric is close to Azure, but there is always a possibility of differences when you get it in the cloud. As long as you build a sandboxed solution and don’t make use of unsupported features (i.e.: PerformancePoint, BCS, etc), more than likely your code will work when it gets to the cloud. There may be things that you can do in a Sandboxed solution in SharePoint 2010 compared to SharePoint Online, but it’s far too early to tell at this point. To get started developing web parts in the cloud, you pretty much need a copy of SharePoint 2010 (or SharePoint Foundation) installed somewhere locally. This could be native on your Windows 7 machine or inside a virtual machine. Wherever it is, you will obviously need Internet access to get your code to the cloud.

To get started developing in the cloud, the first step is to build the web part on your local SharePoint environment. I won’t go through all the steps here, because most of them are the same from my article on 2010 Web Part Development. However, I will go through the important steps. The first step is to create a new Empty SharePoint 2010 Project in Visual Studio 2010. Specify the URL to a local site on your SharePoint server. Don’t use the address of your SharePoint Online site. It won’t work. When prompted for the solution type, choose Sandboxed Solution.

At this point, you have a regular SharePoint project in Visual Studio. Add a web part to the project just like you would in SharePoint 2010. Sticking with the Hello World type example, we put some code like the following in our web part.

using System;

using System.ComponentModel;

using System.Web;

using System.Web.UI;

using System.Web.UI.WebControls;

using System.Web.UI.WebControls.WebParts;

using Microsoft.SharePoint;

using Microsoft.SharePoint.WebControls;

namespace SharePointOnlineProject3.HelloCloudWebPart

{

    [ToolboxItemAttribute(false)]

    public class HelloCloudWebPart : WebPart

    {

        protected override void CreateChildControls()

        {

            Controls.Add(new Label() { Text = "Hello, Cloud!" });

        }

    }

}

At this point, we can test our code locally on our SharePoint server. Build and deploy the project and then add your web part to a test page on your site. Again, if you aren’t familiar with these steps, take a look at my Building and Deploying Web Parts with SharePoint 2010 post. If the code, works you should see a similar page like the one below.

Now, we’re ready to send our web part “to the cloud!”. How do we do that? Start by using the Package menu to build a SharePoint package (.wsp file).

This creates a .wsp file located in the bin folder of the project. We’ll use this file to deploy our web part to the cloud. It’s now time to open up a browser and connect to your instance of SharePoint Online. Once you get there, we deploy a sandboxed solution just like we would on-premises. Go to Site Settings –> Solutions to view the Solutions Gallery. Click on the Solutions button in the ribbon, and then click Upload Solution. Browse to the bin folder of your Visual Studio project and select the file ending in .wsp. Once it uploads, be sure and click the Activate button.

Now, you just need to ensure the feature is activated by going to Site Settings –> Site Collection Features. If it is not activated, click the activate button.

Your web part has now been thrown over the fence and deployed to the cloud! Test it out by going to any page on the site and adding the web part to the page. You’ll find your web part in the Custom section by default. If all goes well, your web part should work here too.

Congratulations, you have now deployed code to the cloud! It’s really not that hard is it? Now, you might be wondering if you can debug your solution. Unfortunately, the answer is no. If you have an issue, you have to step through it locally on your on-premises SharePoint server. That’s all there is to getting started with SharePoint Online development. As you can see it’s very familiar to sandboxed solutions development with your on-premises server.

How to: Provision a Document Set using CAML

CoreyRoth — Mon, 29 Nov 2010 20:53:28 GMT

When it comes to deploying SharePoint artifacts, I pretty much always insist on doing as much as possible using a feature and CAML as opposed to using the UI or writing code. CAML is very possible and most people don’t realize how much you can do with it. The XML scares a lot of people but there are a lot of techniques you can use now in SharePoint 2010 to avoid writing a lot of this manually. This article assumes you have some familiarity in deploying content types and site columns using a feature. If you need more information on this, feel free to ask and I’ll post more on it.

As you probably know a Document Set is simply a content type which contains other content types. For today’s example, I’m going to deploy a Document Set called Work Order. It will contain two child content types: Contract and Invoice. Let’s look at these child content types real quick. Both inherit from Document and I only specifically list my custom site columns in it.

Here is what Contract looks like:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <ContentType ID="0x0101000F9EF6A4CF6E7046A227BC48222671DC" Name="Contract" Group="Custom Content Types" Overwrite="TRUE" xmlns="http://schemas.microsoft.com/sharepoint/">
    <Folder TargetName="_cts/Contract" />
    <FieldRefs>
     
      <FieldRef ID="{6d392ce3-12e0-49f7-ba79-04f2b2e67269}" Name="Contract_x0020_Number" />
      <FieldRef ID="{f7b6fc7c-eb22-43dd-89a5-799874d7a5d7}" Name="Effective_x0020_Date" />
    </FieldRefs>
    <XmlDocuments>
      <XmlDocument NamespaceURI="http://schemas.microsoft.com/sharepoint/v3/contenttype/forms">
        <FormTemplates xmlns="http://schemas.microsoft.com/sharepoint/v3/contenttype/forms">
          <Display>DocumentLibraryForm</Display>
          <Edit>DocumentLibraryForm</Edit>
          <New>DocumentLibraryForm</New>
        </FormTemplates>
      </XmlDocument>
    </XmlDocuments>
  </ContentType>
</Elements>

My Invoice content type looks quite similar. Note that the Contract Number field is shared between the two content types.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <ContentType ID="0x0101006754EF61193E3942B6851FBE641DD21E" Name="Invoice" Group="Custom Content Types" Overwrite="TRUE" xmlns="http://schemas.microsoft.com/sharepoint/">
    <Folder TargetName="_cts/Invoice" />
    <FieldRefs>
      <FieldRef ID="{6d392ce3-12e0-49f7-ba79-04f2b2e67269}" Name="Contract_x0020_Number" />
      <FieldRef ID="{1dfcbcef-d1e1-42a1-bd59-a2079cc7ca36}" Name="Amount" />
    </FieldRefs>
    <XmlDocuments>
      <XmlDocument NamespaceURI="http://schemas.microsoft.com/sharepoint/v3/contenttype/forms">
        <FormTemplates xmlns="http://schemas.microsoft.com/sharepoint/v3/contenttype/forms">
          <Display>DocumentLibraryForm</Display>
          <Edit>DocumentLibraryForm</Edit>
          <New>DocumentLibraryForm</New>
        </FormTemplates>
      </XmlDocument>
    </XmlDocuments>
  </ContentType>
</Elements>

Now how do we deploy the Document Set? It’s actually not that complicated. We define it just like a regular content type that inherits from Content Type Id 0x0120D520. Here is what the first line looks like in the elements.xml for my Document Set. As you can see, I started with that Content Type Id and appended 00, plus my own GUID (minus dashes and brackets).

<ContentType ID="0x0120D5200032EBDCE82398324CAD4E4E21C3233AA7" Name="Work Order" Group="Custom Content Types" Overwrite="TRUE" ProgId="SharePoint.DocumentSet" PushDownChangedResourceFilesOnly="TRUE" xmlns="http://schemas.microsoft.com/sharepoint/">

In the next section, I reference my custom site columns, Contract Number. I included all of the other FieldRef elements that are inherited but I expect you can leave them out.

<FieldRefs>
  <FieldRef ID="{c042a256-787d-4a6f-8a8a-cf6ab767f12d}" Name="ContentType" />
  <FieldRef ID="{b824e17e-a1b3-426e-aecf-f0184d900485}" Name="ItemChildCount" />
  <FieldRef ID="{960ff01f-2b6d-4f1b-9c3f-e19ad8927341}" Name="FolderChildCount" />
  <FieldRef ID="{fa564e0f-0c70-4ab9-b863-0177e6ddd247}" Name="Title" Required="FALSE" Hidden="TRUE" />
  <FieldRef ID="{8553196d-ec8d-4564-9861-3dbe931050c8}" Name="FileLeafRef" Required="TRUE" Hidden="FALSE" />
  <FieldRef ID="{cbb92da4-fd46-4c7d-af6c-3128c2a5576e}" Name="Description" ShowInNewForm="TRUE" ShowInEditForm="TRUE" />
  <FieldRef ID="{6d392ce3-12e0-49f7-ba79-04f2b2e67269}" Name="Contract_x0020_Number" />
</FieldRefs>

The rest of the magic behind Document Sets exists in the XmlDocuments section of the content type. I won’t describe all of them but I will include the ones that are of interest. The most important section describes which content types are in the Document Set. You need to include one AllowedContentType element for each content type included. In this case, I have the Content Type Ids for Document, Contract, and Invoice.

<XmlDocument NamespaceURI="http://schemas.microsoft.com/office/documentsets/allowedcontenttypes">
  <act:AllowedContentTypes xmlns:act="http://schemas.microsoft.com/office/documentsets/allowedcontenttypes" LastModified="11/29/2010 18:57:35">
    <AllowedContentType id="0x0101" />
    <AllowedContentType id="0x0101000F9EF6A4CF6E7046A227BC48222671DC" />
    <AllowedContentType id="0x0101006754EF61193E3942B6851FBE641DD21E" />
  </act:AllowedContentTypes>
</XmlDocument>

The SharedField element specifies which fields are shared between content types. The value of this site column set at the Document Set level will be written into the child content types automatically.

<XmlDocument NamespaceURI="http://schemas.microsoft.com/office/documentsets/sharedfields">
  <sf:SharedFields xmlns:sf="http://schemas.microsoft.com/office/documentsets/sharedfields" LastModified="11/29/2010 18:58:08">
    <SharedField id="6d392ce3-12e0-49f7-ba79-04f2b2e67269" />
  </sf:SharedFields>
</XmlDocument>

The WelcomePageField element controls which site columns show up on the welcome page of the content type. In this case I want the Contract Number displayed so I include that site column’s Id.

<XmlDocument NamespaceURI="http://schemas.microsoft.com/office/documentsets/welcomepagefields">
  <wpf:WelcomePageFields xmlns:wpf="http://schemas.microsoft.com/office/documentsets/welcomepagefields" LastModified="11/29/2010 18:58:08">
    <WelcomePageField id="6d392ce3-12e0-49f7-ba79-04f2b2e67269" />
  </wpf:WelcomePageFields>
</XmlDocument>

Document Sets also give you the ability to create default documents for each content type in the set. The DefaultDocument element is how you do this by specifying a filename and a Content Type Id. I’ll talk about how you actually get the files deployed in the right place here in a little bit.

<XmlDocument NamespaceURI="http://schemas.microsoft.com/office/documentsets/defaultdocuments">
  <dd:DefaultDocuments xmlns:dd="http://schemas.microsoft.com/office/documentsets/defaultdocuments" LastModified="11/29/2010 17:06:58" AddSetName="True">
    <DefaultDocument name="Contract Template.docx" idContentType="0x0101000F9EF6A4CF6E7046A227BC48222671DC" />
    <DefaultDocument name="Invoice Template.xlsx" idContentType="0x0101006754EF61193E3942B6851FBE641DD21E" />
  </dd:DefaultDocuments>
</XmlDocument>

Here is what the whole elements.xml file looks like for my document set. I omitted details on a few of the XmlDocument elements but they seem to always have the same values.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <ContentType ID="0x0120D5200032EBDCE82398324CAD4E4E21C3233AA7" Name="Work Order" Group="Custom Content Types" Overwrite="TRUE" ProgId="SharePoint.DocumentSet" PushDownChangedResourceFilesOnly="TRUE" xmlns="http://schemas.microsoft.com/sharepoint/">
    <Folder TargetName="_cts/Work Order" />
    <FieldRefs>
      <FieldRef ID="{c042a256-787d-4a6f-8a8a-cf6ab767f12d}" Name="ContentType" />
      <FieldRef ID="{b824e17e-a1b3-426e-aecf-f0184d900485}" Name="ItemChildCount" />
      <FieldRef ID="{960ff01f-2b6d-4f1b-9c3f-e19ad8927341}" Name="FolderChildCount" />
      <FieldRef ID="{fa564e0f-0c70-4ab9-b863-0177e6ddd247}" Name="Title" Required="FALSE" Hidden="TRUE" />
      <FieldRef ID="{8553196d-ec8d-4564-9861-3dbe931050c8}" Name="FileLeafRef" Required="TRUE" Hidden="FALSE" />
      <FieldRef ID="{cbb92da4-fd46-4c7d-af6c-3128c2a5576e}" Name="Description" ShowInNewForm="TRUE" ShowInEditForm="TRUE" />
      <FieldRef ID="{6d392ce3-12e0-49f7-ba79-04f2b2e67269}" Name="Contract_x0020_Number" />
    </FieldRefs>
    <XmlDocuments>
      <XmlDocument NamespaceURI="http://schemas.microsoft.com/office/documentsets/defaultdocuments">
        <dd:DefaultDocuments xmlns:dd="http://schemas.microsoft.com/office/documentsets/defaultdocuments" LastModified="11/29/2010 17:06:58" AddSetName="True">
          <DefaultDocument name="Contract Template.docx" idContentType="0x0101000F9EF6A4CF6E7046A227BC48222671DC" />
          <DefaultDocument name="Invoice Template.xlsx" idContentType="0x0101006754EF61193E3942B6851FBE641DD21E" />
        </dd:DefaultDocuments>
      </XmlDocument>
      <XmlDocument NamespaceURI="http://schemas.microsoft.com/office/documentsets/welcomepageview">
        <WelcomePageView xmlns="http://schemas.microsoft.com/office/documentsets/welcomepageview" LastModified="1/1/1 0:00:01 AM" />
      </XmlDocument>
      <XmlDocument NamespaceURI="http://schemas.microsoft.com/office/documentsets/allowedcontenttypes">
        <act:AllowedContentTypes xmlns:act="http://schemas.microsoft.com/office/documentsets/allowedcontenttypes" LastModified="11/29/2010 18:57:35">
          <AllowedContentType id="0x0101" />
          <AllowedContentType id="0x0101000F9EF6A4CF6E7046A227BC48222671DC" />
          <AllowedContentType id="0x0101006754EF61193E3942B6851FBE641DD21E" />
        </act:AllowedContentTypes>
      </XmlDocument>
      <XmlDocument NamespaceURI="http://schemas.microsoft.com/office/documentsets/sharedfields">
        <sf:SharedFields xmlns:sf="http://schemas.microsoft.com/office/documentsets/sharedfields" LastModified="11/29/2010 18:58:08">
          <SharedField id="6d392ce3-12e0-49f7-ba79-04f2b2e67269" />
        </sf:SharedFields>
      </XmlDocument>
      <XmlDocument NamespaceURI="http://schemas.microsoft.com/office/documentsets/welcomepagefields">
        <wpf:WelcomePageFields xmlns:wpf="http://schemas.microsoft.com/office/documentsets/welcomepagefields" LastModified="11/29/2010 18:58:08">
          <WelcomePageField id="6d392ce3-12e0-49f7-ba79-04f2b2e67269" />
        </wpf:WelcomePageFields>
      </XmlDocument>
      <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>DocSetDisplayForm</New>
        </FormTemplates>
      </XmlDocument>
      <XmlDocument NamespaceURI="http://schemas.microsoft.com/sharepoint/v3/contenttype/forms/url">
        <FormUrls xmlns="http://schemas.microsoft.com/sharepoint/v3/contenttype/forms/url">
          <New>_layouts/NewDocSet.aspx</New>
        </FormUrls>
      </XmlDocument>
    </XmlDocuments>
  </ContentType>
</Elements>

Note the path specified in the folder element as this is important. I mentioned that there were extra steps involved in deploying the default documents. For this we need a module element. We also need this module element to deploy the actual page that is displayed when you view the document set. Start by creating a new module in Visual Studio 2010. In the module, create a folder called _cts. Then create a subfolder under that which is unique to your content type. In this case, I named it Work Order to match the name of my content type. Now we need to get a copy of the page that displays when you view the document set. By default, this file is called docsethomepage.aspx. You can find it in 14\FEATURES\DocumentSet. You can also get it by exporting a site template that has a document set. You import the .wsp file in Visual Studio and then look for the corresponding cts module entry. The last step is a bit more involved, but it is how I determined which web parts to include in the module element. Drag this page into your module folder along with the default documents you want for your content type (i.e.: Contact Template.docx and Invoice Template.xlsx).

Here is what my completed module elements.xml looks like.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Module Name="WorkOrderCts">
    <File Path="WorkOrderCts\_cts\Work Order\docsethomepage.aspx" Url="_cts/Work Order/docsethomepage.aspx">
      <AllUsersWebPart WebPartOrder="0" WebPartZoneID="WebPartZone_TopLeft" ID="g_737f2b01_0a4b_4cd9_9c5e_658e2ad65920">
        <![CDATA[<WebPart xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.microsoft.com/WebPart/v2">
  <Title>Image</Title>
  <FrameType>Default</FrameType>
  <Description>Use to display pictures and photos.</Description>
  <IsIncluded>true</IsIncluded>
  <ZoneID>WebPartZone_TopLeft</ZoneID>
  <PartOrder>0</PartOrder>
  <FrameState>Normal</FrameState>
  <AllowRemove>true</AllowRemove>
  <AllowZoneChange>true</AllowZoneChange>
  <AllowMinimize>true</AllowMinimize>
  <AllowConnect>true</AllowConnect>
  <AllowEdit>true</AllowEdit>
  <AllowHide>true</AllowHide>
  <IsVisible>true</IsVisible>
  <HelpMode>Modeless</HelpMode>
  <Dir>Default</Dir>
  <MissingAssembly>Cannot import this Web Part.</MissingAssembly>
  <Assembly>Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c</Assembly>
  <TypeName>Microsoft.SharePoint.WebPartPages.ImageWebPart</TypeName>
  <ImageLink xmlns="http://schemas.microsoft.com/WebPart/v2/Image">/_layouts/images/docset_welcomepage_big.png</ImageLink>
</WebPart>]]>
      </AllUsersWebPart>
      <AllUsersWebPart WebPartOrder="0" WebPartZoneID="WebPartZone_CenterMain" ID="g_8882074f_409f_4ce4_8fb9_7e4ce9aa1d93">
        <![CDATA[<WebPart xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.microsoft.com/WebPart/v2">
  <Title>Document Set Contents</Title>
  <FrameType>Default</FrameType>
  <Description>Displays the contents of the Document Set.</Description>
  <IsIncluded>true</IsIncluded>
  <ZoneID>WebPartZone_CenterMain</ZoneID>
  <PartOrder>0</PartOrder>
  <FrameState>Normal</FrameState>
  <AllowRemove>true</AllowRemove>
  <AllowZoneChange>true</AllowZoneChange>
  <AllowMinimize>true</AllowMinimize>
  <AllowConnect>true</AllowConnect>
  <AllowEdit>true</AllowEdit>
  <AllowHide>true</AllowHide>
  <IsVisible>true</IsVisible>
  <HelpMode>Modeless</HelpMode>
  <Dir>Default</Dir>
  <MissingAssembly>Cannot import this Web Part.</MissingAssembly>
  <PartImageLarge>/_layouts/images/msimagel.gif</PartImageLarge>
  <Assembly>Microsoft.Office.DocumentManagement, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c</Assembly>
  <TypeName>Microsoft.Office.Server.WebControls.DocumentSetContentsWebPart</TypeName>
</WebPart>]]>
      </AllUsersWebPart>
      <AllUsersWebPart WebPartOrder="0" WebPartZoneID="WebPartZone_Top" ID="g_357da23e_61eb_473c_8eac_5609fc574329">
        <![CDATA[<WebPart xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.microsoft.com/WebPart/v2">
  <Title>Document Set Properties</Title>
  <FrameType>Default</FrameType>
  <Description>Displays the properties of the Document Set.</Description>
  <IsIncluded>true</IsIncluded>
  <ZoneID>WebPartZone_Top</ZoneID>
  <PartOrder>0</PartOrder>
  <FrameState>Normal</FrameState>
  <AllowRemove>true</AllowRemove>
  <AllowZoneChange>true</AllowZoneChange>
  <AllowMinimize>true</AllowMinimize>
  <AllowConnect>true</AllowConnect>
  <AllowEdit>true</AllowEdit>
  <AllowHide>true</AllowHide>
  <IsVisible>true</IsVisible>
  <HelpMode>Modeless</HelpMode>
  <Dir>Default</Dir>
  <MissingAssembly>Cannot import this Web Part.</MissingAssembly>
  <PartImageLarge>/_layouts/images/msimagel.gif</PartImageLarge>
  <Assembly>Microsoft.Office.DocumentManagement, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c</Assembly>
  <TypeName>Microsoft.Office.Server.WebControls.DocumentSetPropertiesWebPart</TypeName>
</WebPart>]]>
      </AllUsersWebPart>
    </File>
    <File Path="WorkOrderCts\_cts\Work Order\Invoice Template.xlsx" Url="_cts/Work Order/Invoice Template.xlsx" />
    <File Path="WorkOrderCts\_cts\Work Order\Contract Template.docx" Url="_cts/Work Order/Contract Template.docx" />
  </Module>
</Elements>

The three web parts included in the docsethomepage.aspx file element display the details of the documents set when a user views the page. If you want to customize this page, you could add web parts here or customize docsethomepage.aspx itself. In this section make sure the Url element of each File element contains the path specified in the Folder element of the Document Set content type (_cts/Work Order in this case). With all this put together, your Visual Studio project will look something like this.

At this point, you can deploy this solution. Make sure the destination site collection has the Document Sets feature activated otherwise things won’t work right. If all goes well, you will have a working Document Set with all of the settings you specified. You can go to the Content Types page, edit your content type and look at the Document Set Settings link to verify that it was create successfully.

If everything looks good with your content type, add it to a document library and try creating a new Document Set. If it works right, you will have a new instance of your Document Set and you will see a page like the one below.

As you can see, it successfully created the default documents and it is displaying my Contract Number field.

Ok, this process may seem a bit involved at this point but it’s really not bad. You can always create this stuff in the UI and then export as site template. Once you export a site template, you can import the pieces you want into a new project. I’ll write up a post on this topic in the future as it is a great way to learn how SharePoint 2010 works behind the scenes.

Slides from my SharePoint 2010 Development talk at Tyson Devcon and NWA CodeCamp

CoreyRoth — Mon, 25 Oct 2010 21:14:26 GMT

This last weekend, I had the opportunity to speak at the Tyson Developer Conference as well as the NWA CodeCamp the following day. I spoke about how easy it is for an ASP.NET developer to get started with SharePoint 2010 development. I had a good time at the conference and enjoyed meeting a lot of new people. My slides have been posted on Slide Share. Please, let me know if you have any questions. Thanks.

SharePoint 2010 Development for ASP.NET Developers

How to: Debug a PowerShell Cmdlet

CoreyRoth — Thu, 09 Sep 2010 15:40:29 GMT

In sticking with our theme of debugging things from yesterday, I thought I would write up a quick post on how to debug a cmdlet. This may be obvious to you experienced developers out there, but someone new to writing cmdlets may not be familiar with the process. Luckily, cmdlets are easier to debug than the Custom Index Connectors I talked about yesterday. I hope to educate people as much as I can on how to build cmdlets, so that we can get more contributions to the SharePoint PowerShell Community Toolkit. If you haven’t checked it out yet, please do. :-)

Once you have built your cmdlet, set a breakpoint in your code in Visual Studio. Once you have done that, open a new PowerShell window (or a SharePoint Management Shell) and install your module or snapin. The technique for debugging is the same whether you load your cmdlet with Add-PSSnapin or Import-Module. In Visual Studio, go to Debug –> Attach to Process. Scroll through the list and look for powershell.exe. If you launched PowerShell using the SharePoint 2010 Management Shell icon you will notice the title in the list as shown below.

When you find the right process, select it and click the attach button. Now, go to your PowerShell window and run your command. If all goes according to plan, your breakpoint will be hit and you can step through the code of your cmdlet.

That’s all there is to it. Isn’t developing for PowerShell easy? The snippet of code you see above is actually from a new cmdlet I am releasing soon in the SharePoint PowerShell Community Toolkit that lets you test search queries from the command line. I’ve already found it to be a handy cmdlet when I want to test a query using the API quickly.

How to: Change your namespace in a Silverlight application without breaking everything

CoreyRoth — Fri, 23 Jul 2010 20:16:41 GMT

The first thing I do when creating a new project in Visual Studio (regardless of type) is change the project name, assembly name, and default namespace. I like for the names of all these to be consistent. However, I have noticed in Silverlight, you must make changes in five different places for everything to work alright otherwise you will get errors. I’m no Silverlight expert, but I thought this post would be useful for people like me who only dabble in it from time to time.

When you create your new Silverlight project, right click on the project name and bring up its properties. Go ahead and change the default namespace and assembly name just like you would in any other project.

In my case, I change from a namespace of SilverlightApplication1 to DotNetMafia.Silverlight.Test. Here you can see the new assembly name and default namespace. There are two other options to set here, but we will have to come back to it.

At this point, we want to correct the namespace in the existing classes. Let’s start with App.xaml.

I have highlighted the section, I need to change, x:Class. I’ll change it to DotNetMafia.Silverlight.Test like we see below.

Now, we just need to change the namespace in the code behind file App.xaml.cs.

Now, we have to do the same thing to MainPage.xaml. Change the namespace here on x:Class as well.

Then, you will change the namespace of the code behind file MainPage.xaml.cs just liked we did before.

At this point, your code will compile. However, it will not run. If you try to debug it you will likely get a blank page and if you are using Internet Explorer, you will probably see a script error in the toolbar.

Clicking on the error, you can see the following details.

I have to say they have really improved the way you view script errors. Here is the text of the error.

Message: Unhandled Error in Silverlight Application
Code: 2103
Category: InitializeError
Message: Invalid or malformed application: Check manifest

Line: 54
Char: 13
Code: 0
URI: file:///C:/Code/SilverlightApplication1/Bin/Debug/SilverlightApplication1TestPage.html

Remember, I said we had to change an additional setting in the project properties?

This is the problem here. We change the startup objects namespace but never update the project properties to match. You should be able to pick the new namespace of your startup object from the list. This is also a good time to change the name of your .XAP file if you are so inclined. Here is what my project properties looks like when I am done.

At this point your application should compile and run. Now I can view my beautiful Hello World Silverlight application.

Great app huh? Any how, I hope this helps should you encounter the error above or run into issues changing your namespace. It’s pretty simple to do, but you’ll definitely get errors if you don’t get all of your changes made.

Visual Web Parts in MOSS 2007

CoreyRoth — Fri, 16 Jul 2010 19:01:14 GMT

Yesterday, I showed you how to deploy a regular web part to MOSS 2007 / WSS3 that was built and packaged in Visual Studio 2010. Today, we can take that a step further and take advantage of the new Visual Web Part and deploy it the same way. If you remember, a Visual Web Part is nothing more than a glorified user control. To get started, create a new empty SharePoint project or use and existing one. If you need assistance with that, look at yesterday’s post. Then, go ahead and create a new Visual Web Part. The user control Visual Studio creates has many references to SharePoint 2010 DLLs that we simply do not need (or can use). These must be removed. Here is what it looks like when we start.

<%@ Assembly Name="$SharePoint.Project.AssemblyFullName$" %>
<%@ Assembly Name="Microsoft.Web.CommandUI, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %> 
<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %> 
<%@ Register Tagprefix="Utilities" Namespace="Microsoft.SharePoint.Utilities" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="asp" Namespace="System.Web.UI" Assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" %>
<%@ Import Namespace="Microsoft.SharePoint" %> 
<%@ Register Tagprefix="WebPartPages" Namespace="Microsoft.SharePoint.WebPartPages" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Control Language="C#" AutoEventWireup="true" CodeBehind="VisualWebPart1UserControl.ascx.cs" Inherits="WSSWebPart.VisualWebPart1.VisualWebPart1UserControl" %> 

Remove any reference to a SharePoint version 14 DLL and you will have a file that looks like this. Then I’m just going to add a simple label to demonstrate our user control. Here is what it looks like after the changes.

<%@ Assembly Name="$SharePoint.Project.AssemblyFullName$" %>
<%@ Register Tagprefix="asp" Namespace="System.Web.UI" Assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" %>
<%@ Import Namespace="Microsoft.SharePoint" %> 
<%@ Control Language="C#" AutoEventWireup="true" CodeBehind="VisualWebPart1UserControl.ascx.cs" Inherits="WSSWebPart.VisualWebPart1.VisualWebPart1UserControl" %>
<asp:Label ID="MyLabel" runat="server" Text="Hello, world!  Visual Web Part compiled in Visual Studio 2010!" /> 

You can replace, the version 14 references with version 12 references if you really need them. However, I find that most of the time, I am really only using standard ASP.NET controls so they are unnecessary. That is all you have to do. Assuming you started with a solution from yesterday, you can package the project and install the .wsp file on your SharePoint 2007 server using STSADM. If you created a new project don’t forget to remember to remove the SharePoint version attribute in the Package properties (discussed in yesterday’s post). Here is what my Visual Web Part looks like running on SharePoint 2007.

It’s pretty simple to do. I am able to leverage the simplicity of the Visual Web Part and take advantage of Visual Studio 2010 building my .wsp file. The more I work with Visual Studio 2010, the more I realize I can use SharePoint Project Items in previous versions of SharePoint with just a little bit of work.

Using Visual Studio 2010 SharePoint Templates to deploy a web part in SharePoint 2007

CoreyRoth — Thu, 15 Jul 2010 21:34:00 GMT

That’s a mouth full. I always suspected it was possible to use Visual Studio 2010 to package up my SharePoint web parts and other artifacts into a solution (.wsp file) and turn around and deploy that code into MOSS 2007. Today I gave it a try and it actually works pretty well. This post will show you how to do it. I will remind you that you won’t be able to take advantage of any of the automatic deployment, debugging features built into Visual Studio 2010 and SharePoint 2010, but you will have a nice solution file that was built automatically without having to use a third party tool like WSPBuilder. You can then take the solution package and deploy it to SharePoint with stsadm.

I will start off by using the SharePoint 2010 Empty Project Template. Now, unfortunately, the wizard that starts this project has a dependency on SharePoint 2010. It simply won’t run without it. However, if you happen to already have a copy of a project that has been created, you can open an existing SharePoint 2010 project template on a computer that does not have SharePoint installed. I have attached a copy of my Visual Studio solution for you to use as a starting point if you need it.

Once I have my project open, I proceed to create a web part as shown below in the Solution Explorer.

I don’t have to make any modifications to the class. So I add some simple “Hello, World!” code to it.

We’re targeting SharePoint version 3, so that means we need to change some references. All of the DLLs in SharePoint 2010 are version 14. We need version 12 DLLs. So what you will need to do is go get a copy of Microsoft.SharePoint.dll (and possibly Microsoft.SharePoint.Security.dll) from your version 3 SharePoint farm. We then need to remove the reference to the version 14 DLLs. Click on Microsoft.SharePoint.dll and Microsoft.SharePoint.Security.dll and remove them from the solution. We then add our version 12 DLLs to the references list and we’re ready to compile our web part for WSS3.

At this point, I will remind you of the caveats of perusing this completely unsupported approach. Obviously, you can’t need to make sure you are only using API calls from version 3. Using a class from SharePoint 2010 is obviously not going to work.

Build your project and it should compile successfully. Now, I figured everything would work at this point but I discovered one thing that I had to change in this process. The SharePoint 2010 solution schema has a new attribute called SharePoint version on the SharePoint element. WSS3 does not like this.

Luckily, I discovered, that if we delete the value from the property window, it actually removes the attribute.

Simply, remove the value there and we are ready to package the project.

When this is complete, you can browse the file system and find your .wsp file in the bin folder. Copy the .wsp file to the SharePoint 2007 server if you aren’t already on it. Then add and deploy the package with stsadm. At this point, you will have a feature that you can activate on your SharePoint 2007 server. Go to site collection features and activate it.

The web part should now be in the Solution Gallery. Now edit a page, and add a new web part. Your web part should be in the group labeled Custom assuming you haven’t changed it.

We can now verify that the web part code works on the page.

As you can see it’s really pretty easy to build a WSS3 web part in Visual Studio 2010 and deploy it. We lose some of the cool VS2010/SP2010 integration features of course, but the fact it builds the package for us is a huge win. Not to mention, upgrading our code to work in SharePoint 2010 later will be pretty easy since all we have to do is change our references from the version 12 to the version 14 DLLs. I’ve only covered how to do a web part here today. I suspect other SharePoint Project Items will work as well. I’ll try them out soon and let you know how they work. As a reminder, I have attached a copy of my solution to this post for you to use in case you don’t have SharePoint 2010 installed any where. Give it a try and let me know if it works for you.

Slides from my talk at SharePoint Saturday Ozarks

CoreyRoth — Mon, 28 Jun 2010 20:52:50 GMT

Sorry. I’ve been slacking this month. With SharePoint Saturday Ozarks, vacation, and having my laptop stolen, I’ve been way behind on blogging. I’ve also been way behind in posting my slides from #SPSOzarks. If you weren’t at the event you missed a good time. As always, @mrackley provided us with a good event and plenty of fun. Anyhow, my slides have actually been up for a while on SlideShare.net. Thanks for having me and I’ll see you at the next event. You should start seeing more posts from me soon. I’m a little behind rebuilding my new laptop. I also lost my production SharePoint 2010 images thanks to the thief that has my laptop. Yeah, I know I should have had them backed up, but I never got around to it. That’s my fault. I won’t make that mistake again. :-)

A few quick tips for interacting with the file system in Visual Studio

CoreyRoth — Wed, 07 Apr 2010 18:59:52 GMT

I was doing some SharePoint mentoring a while back and I noticed that some developers don’t know about a couple handy items found in various context menus that that I use on a daily basis. Specifically I’m talking about a few things in the context menu that give you the path to the file or open the folder that the file is in. These can be useful when you are ghetto deploying files or you simply want to jump to the file system to grab your .wsp file. Honestly these menu items have been around for a long time, but I hadn’t noticed them until a while back. If you already know about them, you can stop reading here. :-)

The first menu I want to talk about is the context menu you get by right clicking on the tab of any open file. This is from Visual Studio 2010, but its there in 2008 as well. I’m not sure about 2005, but if you are still using Visual Studio 2005, you should be ashamed of yourself.

The two menu items of interest here are Copy Full Path and Open Containing Folder. As expected, Copy Full Path puts the full path to the file in the clipboard. This is great when you have a file open in Visual Studio and you need to upload it via browser File Upload control. You can just paste the path right in and you’re good to go. I use this when I’m uploading BDC application definitions a lot. The Open Containing Folder is useful any time you need to copy the file in your project from one place to another.

If you don’t have a file open, you can make use of another item on the context menu from the Solution Explorer.

This opens the folder the file is in with windows explorer.

Directory structures for source code can be huge these days. Lots of nested folders and it takes time to click through them. I mention these topics today because I’ve watched developers open a new instance of windows explorer and browse through the folder structure every time. Anyhow, maybe you already use these menu options. I thought they were useful and worth a quick mention.

Ctrl+Comma – The Navigate To Window in Visual Studio 2010

CoreyRoth — Fri, 26 Feb 2010 20:06:03 GMT

I attended the monthly Microsoft Solution Advocate call this morning and during the demo of some cool code you use in your Windows 7 applications, they pointed out a new feature in Visual Studio 2010 that I hadn’t seen before. When you press Ctrl+Comma (,), it brings up the new Navigate To window.

This window allows you to do a quick search for classes and methods that are in your solution. If you have Resharper installed, I think this key combination is already bound, so this may not work. Typing in a few letters, gives you results that look this.

As you can see it brings up methods that are in my solution. You can also type class names and various other things. Now before you start, I am sure this was already in Resharper years ago, but it’s still kind of a neat feature. Try it out.

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.

Does Save Site as Template preserve Version History in sp2010?

CoreyRoth — Thu, 11 Feb 2010 22:18:26 GMT

It looks like the answer is no. When you click the Include Content checkbox on the Save as Template page, it looks like only the latest version of documents and lists items are included in the .wsp file. I ran a few tests and here is what I saw. Consider the following document with its history from the source site.

After I export the site, install and activate the solution on a new site collection and then use the Create Site menu to create a new instance of my site template, only the latest version of the document is there. Now, I’m not complaining as this is already a great step in the right direction and it really does make moving things around between servers easier. In the screenshot below though, you can see that only the latest version is present.

I’m not really sure why it creates two versions of the document (with different file sizes even), but I am sure there is a reason. If you haven’t use Save Site as Template, be sure and check it out. It does export content (including documents). Your documents are packaged up in the .wsp and use the module element to copy them via feature to your document library. Here is what your package looks like in Visual Studio 2010.

As you can tell from my string of posts lately, I am really excited about the Save Site as Template functionality. We all would have killed to have it in WSS3. It really is a great way to see how things are built behind the scenes to using CAML.

Linking Files in Visual Studio

CoreyRoth — Wed, 20 Jan 2010 15:29:35 GMT

I saw this feature in Visual Studio again the other day and honestly I had kind of forgotten about it. After discussing it with some colleagues, most of them didn’t even know the feature existed. What I am talking about is the ability to create a link between files in Visual Studio. What this allows you to do is actually create a link to a file instead of just making a copy. Now, I don’t want to get into a discussion of why you would never want to do this or how this is not a proper way to implement code reuse. Keep in mind though that you can use it to link other types of non-code files such as an XML file. However, for today’s purpose, I’m just going to link a class into another project. Consider my following example with two class libraries. I want to reuse Class1.cs inside ClassLibrary2.

I have a simple class that looks like this.

using System;
 
namespace ClassLibrary1
{
    public class Class1
    {
        public Class1()
        {
        }
 
        public void DoSomething()
        {
            int x = 5;
        }
    }
}

This class clearly has so much valuable code in it that I have to reuse it in ClassLibrary2, but not make a reference to ClassLibrary2. This is where the Add as Link functionality comes in. The process is simple, using the Add Existing Item menu on the project’s context menu. Navigate to the existing item in the other class library and then make note of the arrow next to the Add button, click on it and choose Add as Link instead.

Once you do that you will have a link to the file in your other class library. You can open it and edit it as normal from the linked location, but it will actually edit the file link. You can tell it is linked in Solution Explorer by the icon.

Notice the link icon on Class1.cs in ClassLibrary2. If you click on the linked file, you can see the path to the file it has linked in the properties (although its cut off here in my screenshot).

Once you are done here, you can make changes to the file from either class library and the original file gets updated. Keep in mind though, if you delete the original file, the link will be broken and you will get an error when trying to view any links. I don’t know how useful this feature will be to all of you, but I think there is a time and place for everything. I can definitely see this being useful in some cases. This isn’t a new feature either. I think its been around since at least Visual Studio 2003, but I could be wrong.