Corey Roth [MVP] : WebPart

How to: Build Client Web Parts in SharePoint 2013 with Office Developer Tools RTM

CoreyRoth — Tue, 09 Apr 2013 20:37:44 GMT

This is the third time (and hopefully final) I am writing this post about building Client Web Parts (App Parts) for SharePoint 2013 with Visual Studio 2012. This is largely due to the Office Developer Tools going through a few iterations (Preview 1 and Preview 2). I don’t want to leave out-dated information out there, so here is the updated version. The process remains largely the same, but a few of the screens have changed and what Visual Studio produces for us has changed significantly since Preview 1.

When you create the project, the first two steps look pretty much the same as Preview 1 and Preview 2.

The next step looks the same as well. For our example, we’ll go with a SharePoint-hosted app again.

The good news is, in Preview 2 they’ve added a wizard that helps you get stared with client web parts. This wizard does three things for you. It creates an application page for the client web part, it add it to elements.xml, and it registers the CSS files from SharePoint so that the content inside the IFRAME is styled appropriately. They have also added all of the required JavaScript files you need. I’ll talk about those more in a second. Once you have created the project, add a new item, and choose Client Web Part (Host Web).

You’ll notice on the list that there is a new entry for Search Configuration as well. I talked about that last week in a previous post. When you go to the next step, you get a new dialog in the wizard that gives you the option to create a new page for the client web part. This dialog has been updated slightly since Preview 2.

When you complete the wizard, it will generate quite a bit of HTML and JavaScript including all of the script files needed to get started referencing SharePoint. Let me post the whole code snippet, so you can see what I mean.

<%@ Page language="C#" Inherits="Microsoft.SharePoint.WebPartPages.WebPartPage, Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="Utilities" Namespace="Microsoft.SharePoint.Utilities" Assembly="Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="WebPartPages" Namespace="Microsoft.SharePoint.WebPartPages" Assembly="Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
 
<WebPartPages:AllowFraming ID="AllowFraming" runat="server" />
 
<html>
<head>
    <title></title>
 
    <script type="text/javascript" src="../Scripts/jquery-1.7.1.min.js"></script>
    <script type="text/javascript" src="/_layouts/15/MicrosoftAjax.js"></script>
    <script type="text/javascript" src="/_layouts/15/sp.runtime.js"></script>
    <script type="text/javascript" src="/_layouts/15/sp.js"></script>
 
    <script type="text/javascript">
        'use strict';
 
        // Set the style of the client web part page to be consistent with the host web.
        (function () {
            var hostUrl = '';
            if (document.URL.indexOf('?') != -1) {
                var params = document.URL.split('?')[1].split('&');
                for (var i = 0; i < params.length; i++) {
                    var p = decodeURIComponent(params[i]);
                    if (/^SPHostUrl=/i.test(p)) {
                        hostUrl = p.split('=')[1];
                        document.write('<link rel="stylesheet" href="' + hostUrl + '/_layouts/15/defaultcss.ashx" />');
                        break;
                    }
                }
            }
            if (hostUrl == '') {
                document.write('<link rel="stylesheet" href="/_layouts/15/1033/styles/themable/corev15.css" />');
            }
        })();
    </script>
</head>
<body>
</body>
</html>

The above code differs from Preview 2 in that it also includes references to MicrosoftAjax.js, sp.runtime.js and sp.js. Why we never bothered to include scripts this way in the past is beyond me. In the past, we used $.getScript to dynamically load the SharePoint scripts. That’s way over complicated when you can just get it out of the layouts directory.

At this point, I recommend adding another script file to your project. I tend to go with one script per client web part. You can put all of your script code in there. At this point, you’re also ready to deploy the client web part and try it out. Deploy, your project, click on the Developer Site link, and then edit the page. Click App Part and then choose your newly deployed client web part.

That should get your started. On a related note, the JavaScript code also changed slightly in App.js (the script file for your default.aspx page). Here’s what it looks like if you’re curious.

The new tools make it much easier to get started with Client Web Parts, so be sure and get them if you haven’t already. Also take a look at my Preview 1 and Preview 2 posts as they can walk you through some of the other steps.

How to: Use the SharePoint 2013 Client Object Model (SP.js) from a Client Web Part

CoreyRoth — Fri, 19 Oct 2012 18:13:26 GMT

I was talking to Tom Resing (@resing) last week about using the SharePoint Client Object Model inside a Client Web Part and it became apparent that I left you all hanging with my last post. I got you to the point where you could build your web part, but referencing SP.js is not as simple as you would think it would be. I had to look at a lot of code samples to put this all together. This follow-up post will give you the necessary steps to get started working with SharePoint right away.

The first thing I do is add some script references to the page. For Client Web Parts, I tend to use a new .js file to host the web part’s JavaScript and I leave app.js to serve the needs of Default.aspx. Building on my example from the last post, I add a new script called HelloWorldClientWebPart.js. I add this in the Scripts folder.

We’ll add our code to this file in a minute but first I want to add those references. In this case, we aren’t loading a reference to SP.js yet. Instead, we’ll load jQuery from a CDN as well as MicrosoftAjax.js. You may not need all of those, but chances are you do.

<head>
    <script type="text/javascript" src="../Scripts/jquery-1.6.2.min.js"></script>
    <script type="text/javascript" src="//ajax.aspnetcdn.com/ajax/4.0/1/MicrosoftAjax.js"></script>
    <script type="text/javascript" src="../Scripts/HelloWorldClientWebPart.js"></script>
</head>

Now we’ll jump over to our new script file. We’re going to borrow a few lines from App.js starting with variables to hold the context, web, and user.

var context;
var web;
var user;

Now we use jQuery’s document.ready function to add our code.

$(document).ready(
    function () {
    }
 );

You can add this line to your document.ready function to get a reference to the SPSite object of the site hosting the client web part (app part) as opposed to the site actually hosting the app itself. We’ll also need it to get our reference to SP.js as well.

//Get the URI decoded SharePoint site url from the SPHostUrl parameter.
var spHostUrl = decodeURIComponent(getQueryStringParameter('SPHostUrl'));

This method relies on getQueryStringParameter which you’ll find in many App examples.

function getQueryStringParameter(urlParameterKey) {
    var params = document.URL.split('?')[1].split('&');
    var strParams = '';
    for (var i = 0; i < params.length; i = i + 1) {
        var singleParam = params[i].split('=');
        if (singleParam[0] == urlParameterKey)
            return decodeURIComponent(singleParam[1]);
    }
}

To get the host URL, you will have to modify your elements.xml to make this work. Do this by adding {standardtokens} to the URL of the Content element.

<Content Type="html" Src="~appWebUrl/Pages/HelloWorldClientWebPart.aspx?{StandardTokens}" />

When you do this, SharePoint will automatically pass you a number of query string parameters that you can take advantage of including the SPHostUrl. At that point you can pass the URL into your call to get a SPWeb object.

Back in the JavaScript file, we add the rest of our code. First we need to get the URL to the 15 folder inside _layouts and assign it to our layoutsRoot variable. Now we can use the jQuery getScript() method to retrieve the scripts we need. Before you get SP.js, you have to get SP.Runtime.js. That is why you see the nested calls below. Once SP.js can be retrieved, it makes a call to the execOperation method. This method can then take advantage of the SharePoint Client Object Model.

//Build absolute path to the layouts root with the spHostUrl
var layoutsRoot = spHostUrl + '/_layouts/15/';
 
$.getScript(layoutsRoot + "SP.Runtime.js", function () {
    $.getScript(layoutsRoot + "SP.js", execOperation);
}
);

To demonstrate it’s use, we’ll use the same script example used in App.js. We start by defining execOperation and getting a reference to the content and SPSite object.

function execOperation() {
    // get context and then username
    context = new SP.ClientContext.get_current();
    web = context.get_web();
 
    getUserName();
}

We then use the same getUserName() and other functions from App.js.

function getUserName() {
    user = web.get_currentUser();
    context.load(user);
    context.executeQueryAsync(onGetUserNameSuccess, onGetUserNameFail);
}
 
// This function is executed if the above OM call is successful
// It replaces the content of the 'welcome' element with the user name
function onGetUserNameSuccess() {
    $('#message').text('Hello ' + user.get_title());
}
 
// This function is executed if the above OM call fails
function onGetUserNameFail(sender, args) {
    alert('Failed to get user name. Error:' + args.get_message());
}

Putting the entire script together, here is what it looks like.

var context;
var web;
var user;
 
//Wait for the page to load
$(document).ready(
    function () {
        //Get the URI decoded SharePoint site url from the SPHostUrl parameter.
        var spHostUrl = decodeURIComponent(getQueryStringParameter('SPHostUrl'));
 
        //Build absolute path to the layouts root with the spHostUrl
        var layoutsRoot = spHostUrl + '/_layouts/15/';
 
        $.getScript(layoutsRoot + "SP.Runtime.js", function () {
            $.getScript(layoutsRoot + "SP.js", execOperation);
        }
        );
 
        // Function to execute basic operations.
        function execOperation() {
            // get context and then username
            context = new SP.ClientContext.get_current();
            web = context.get_web();
 
            getUserName();
        }
    }
 );
 
function getQueryStringParameter(urlParameterKey) {
    var params = document.URL.split('?')[1].split('&');
    var strParams = '';
    for (var i = 0; i < params.length; i = i + 1) {
        var singleParam = params[i].split('=');
        if (singleParam[0] == urlParameterKey)
            return decodeURIComponent(singleParam[1]);
    }
}
 
// This function prepares, loads, and then executes a SharePoint query to get the current users information
function getUserName() {
    user = web.get_currentUser();
    context.load(user);
    context.executeQueryAsync(onGetUserNameSuccess, onGetUserNameFail);
}
 
// This function is executed if the above OM call is successful
// It replaces the content of the 'welcome' element with the user name
function onGetUserNameSuccess() {
    $('#message').text('Hello ' + user.get_title());
}
 
// This function is executed if the above OM call fails
function onGetUserNameFail(sender, args) {
    alert('Failed to get user name. Error:' + args.get_message());
}

Lastly, I update HelloWorldClientWebPart.aspx with a div to hold the results. Here is what the entire file looks like.

<%@ Register Tagprefix="WebPartPages" Namespace="Microsoft.SharePoint.WebPartPages" Assembly="Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<WebPartPages:AllowFraming ID="AllowFraming1" runat="server" />
<head>
    <script type="text/javascript" src="../Scripts/jquery-1.6.2.min.js"></script>
    <script type="text/javascript" src="//ajax.aspnetcdn.com/ajax/4.0/1/MicrosoftAjax.js"></script>
    <script type="text/javascript" src="../Scripts/HelloWorldClientWebPart.js"></script>
</head>
<div>
    <h2>Hello World Client Web Part!</h2>
    <div id="message"></div>
</div>

We can then execute the app in the debugger and then add the App Part to the root page of our developer site. It should look something like this when you’re done.

Sorry to leave you hanging like that on my previous blog post. I hope this helps you get started with your app. It’s a bit involved but not too bad. It would be nice to create a custom SharePoint Project Item that does this for us.

Come see my sessions at SPC12 and follow me on twitter @coreyroth.

File not found error on AllItems.apsx list pages using KWizCom web parts

CoreyRoth — Tue, 24 Apr 2012 02:10:29 GMT

Recently, a client of mine acquired some KWizCom web parts. I installed them and they seemed to work fine. However, during the configuration, we ended up building a new web application or two. On these web applications, I started to notice that we were receiving File not found errors whenever you went to AllItems.aspx on any list page (i.e.: Shared Documents, Web Part Gallery, Solution gallery, etc). I immediately thought it was an issue with how I was applying custom branding but that turned out to not be the case. Ultimately, I started seeing this issue on brand new web applications and site collections and I knew something had to be up. Whenever I visited one of these pages that had the issue I got the following error.

File Not Found.

When this occurs you can view the Web Parts Maintenance Page but it is of no help obviously. Ultimately, I queried the ULS log using Get-SPLog using tips I picked up from Wictor. Be sure and use the –StartTime parameter to limit the scope of the query. It will return something much faster. Just paste your Correlation ID in the script and you are good to go.

Get-SPLogEvent -StartTime (Get-Date).AddMinutes(-5) | ?{$_.Correlation -eq "74adb0a7-655a-473b-9afa-5cc9edcc1aed"} | ft Category, Message –AutoSize

After the script executed, the culprit finally stood out.

There from the snippet, you see mention of KWizCom. Now it is all making sense. In this case, we had some of the web parts that do various things to lists. As my first attempt at a solution, I redeployed all of the KWizCom solution packages. That still didn’t help though. I then tried activating all of the site collection features from KWizCom to see if that made a difference and that didn’t work either. Finally, I just retracted all of the solution packages and my lists started working again. I haven’t yet redeployed the solution packages, but I suspect they should probably work, but it makes me leery. This was killing brand new web applications. When I try it again, I’ll update the post.

A look at Visual Web Parts in Visual Studio 11

CoreyRoth — Thu, 12 Jan 2012 16:23:15 GMT

I recently published my first post about SharePoint development with Visual Studio 11 and I mentioned that there were some changes in how the Visual Web Part worked. If you are familiar with the Visual Web Part in Visual Studio 2010, you know it really is just a glorified user control and it doesn’t work in the sandbox. Luckily, the community stepped up and provided some alternatives that do work. Visual Studio 11 now provides a Visual Web Part that works in the sandbox out of the box. Since I am always curious about how things work, I decided to take a deeper look to see just how this web part is implemented now.

Let’s first take a look at the files that we get when we add a Visual Web Part to the project.

There are actually a few less files that we had in Visual Studio 2010. We’ll see why here shortly. What we get are the following

Elements.xml – Used to deploy the .webpart file via module element
A .ascx file – The actual user control with the design surface
A .ascx.cs file – The code behind for the user control
A .ascx.g.cs file – This file is generated by the designer. We’ll talk about it more
A .webpart file – The file that goes into the Web Part gallery that has the assembly path to the web part

If we look at the .ascx.cs file, we’ll see our first difference.

using System;
using System.ComponentModel;
using System.Web.UI.WebControls.WebParts;
 
namespace SharePointProject1.HelloWorldWebPart
{
    [ToolboxItemAttribute(false)]
    public partial class HelloWorldWebPart : WebPart
    {
        protected override void OnInit(EventArgs e)
        {
            base.OnInit(e);
            InitializeControl();
        }
 
        protected void Page_Load(object sender, EventArgs e)
        {
        }
    }
}

You’ll notice that this file inherits from WebPart now instead of UserControl. At this point, you might be wonder how does all of this work. Well, the magic is in the designer and what ends up in the .ascx.g.cs file. Let’s take a look at it when it’s first created.

//------------------------------------------------------------------------------
// <auto-generated>
//     This code was generated by a tool.
//     Runtime Version:2.0.50727.5448
//
//     Changes to this file may cause incorrect behavior and will be lost if
//     the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------
 
namespace SharePointProject1.HelloWorldWebPart {
    using System.Web;
    using System.Text.RegularExpressions;
    using Microsoft.SharePoint.WebPartPages;
    using Microsoft.SharePoint.WebControls;
    using System.Web.Security;
    using Microsoft.SharePoint.Utilities;
    using System.Web.UI;
    using System;
    using System.Web.UI.WebControls;
    using System.Collections.Specialized;
    using Microsoft.SharePoint;
    using System.Collections;
    using System.Web.Profile;
    using System.Text;
    using System.Web.Caching;
    using System.Configuration;
    using System.Web.UI.WebControls.WebParts;
    using System.Web.SessionState;
    using System.Web.UI.HtmlControls;
 
 
    public partial class HelloWorldWebPart {
 
        public static implicit operator global::System.Web.UI.TemplateControl(HelloWorldWebPart target) 
        {
            return target == null ? null : target.TemplateControl;
        }
 
        [global::System.ComponentModel.EditorBrowsableAttribute(global::System.ComponentModel.EditorBrowsableState.Never)]
        private void @__BuildControlTree(global::SharePointProject1.HelloWorldWebPart.HelloWorldWebPart @__ctrl) {
        }
 
        private void InitializeControl() {
            this.@__BuildControlTree(this);
            this.Load += new global::System.EventHandler(this.Page_Load);
        }
 
        [global::System.ComponentModel.EditorBrowsableAttribute(global::System.ComponentModel.EditorBrowsableState.Never)]
        protected virtual object Eval(string expression) {
            return global::System.Web.UI.DataBinder.Eval(this.Page.GetDataItem(), expression);
        }
 
        [global::System.ComponentModel.EditorBrowsableAttribute(global::System.ComponentModel.EditorBrowsableState.Never)]
        protected virtual string Eval(string expression, string format) {
            return global::System.Web.UI.DataBinder.Eval(this.Page.GetDataItem(), expression, format);
        }
    }
}

It may not make a lot of sense at this point, but when you start adding controls, it makes more sense. I added a label, textbox, and button control to the design surface.

This looks like a typical user control that you are confortable working with. Now let’s take a look at what the .ascx.g.cs file has now. I’ll just include the parts that changed.

[global::System.ComponentModel.EditorBrowsableAttribute(global::System.ComponentModel.EditorBrowsableState.Never)]
private global::System.Web.UI.WebControls.Label @__BuildControlLabel1() {
    global::System.Web.UI.WebControls.Label @__ctrl;
    @__ctrl = new global::System.Web.UI.WebControls.Label();
    this.Label1 = @__ctrl;
    @__ctrl.ApplyStyleSheetSkin(this.Page);
    @__ctrl.ID = "Label1";
    @__ctrl.Text = "Label";
    return @__ctrl;
}
 
[global::System.ComponentModel.EditorBrowsableAttribute(global::System.ComponentModel.EditorBrowsableState.Never)]
private global::System.Web.UI.WebControls.TextBox @__BuildControlTextBox1() {
    global::System.Web.UI.WebControls.TextBox @__ctrl;
    @__ctrl = new global::System.Web.UI.WebControls.TextBox();
    this.TextBox1 = @__ctrl;
    @__ctrl.ApplyStyleSheetSkin(this.Page);
    @__ctrl.ID = "TextBox1";
    return @__ctrl;
}
 
[global::System.ComponentModel.EditorBrowsableAttribute(global::System.ComponentModel.EditorBrowsableState.Never)]
private global::System.Web.UI.WebControls.Button @__BuildControlButton1() {
    global::System.Web.UI.WebControls.Button @__ctrl;
    @__ctrl = new global::System.Web.UI.WebControls.Button();
    this.Button1 = @__ctrl;
    @__ctrl.ApplyStyleSheetSkin(this.Page);
    @__ctrl.ID = "Button1";
    @__ctrl.Text = "Button";
    return @__ctrl;
}
 
[global::System.ComponentModel.EditorBrowsableAttribute(global::System.ComponentModel.EditorBrowsableState.Never)]
private void @__BuildControlTree(global::SharePointProject1.HelloWorldWebPart.HelloWorldWebPart @__ctrl) {
    System.Web.UI.IParserAccessor @__parser = ((System.Web.UI.IParserAccessor)(@__ctrl));
    @__parser.AddParsedSubObject(new System.Web.UI.LiteralControl("\r\n<div>\r\n    "));
    global::System.Web.UI.WebControls.Label @__ctrl1;
    @__ctrl1 = this.@__BuildControlLabel1();
    @__parser.AddParsedSubObject(@__ctrl1);
    @__parser.AddParsedSubObject(new System.Web.UI.LiteralControl("\r\n    "));
    global::System.Web.UI.WebControls.TextBox @__ctrl2;
    @__ctrl2 = this.@__BuildControlTextBox1();
    @__parser.AddParsedSubObject(@__ctrl2);
    global::System.Web.UI.WebControls.Button @__ctrl3;
    @__ctrl3 = this.@__BuildControlButton1();
    @__parser.AddParsedSubObject(@__ctrl3);
    @__parser.AddParsedSubObject(new System.Web.UI.LiteralControl("\r\n</div>\r\n"));
}

The designer creates methods for each ASP.NET control you drag onto the page and then the @__BuiltControlTree method calls those methods to effectively add those controls to the page. The HTML div elements that I added to the page simply get included as a LiteralControl. Needless to say you don’t want to mess with this file. I have to give props to the Visual Studio and SharePoint teams. I am sure this was a lot of work to implement. :) Give it a try if you want. It seems to work well and the best part is what I have tried so far works with SharePoint Online.

If you haven’t checked out Visual Studio 11 yet, head over to the developer site where you can get the download link and find out everything that’s new.

How to: Use Visual Studio 11 to publish solutions to SharePoint Online

CoreyRoth — Wed, 11 Jan 2012 05:23:27 GMT

So I’ve been living under a rock again and I had never gotten around to checking what’s new in Visual Studio 11. The Developer Preview has been around a while and I wanted to check it out today and was surprised to see some new SharePoint development features that I am really excited about. If you have been following me, you know I have been doing some work with Office 365 and SharePoint Online, so when I read about the new Publish feature in Visual Studio 11, I had to check it out. Let’s start by creating a new project with a simple web part. We’ll look and what’s new and see how exactly we can publish to SharePoint Online.

Open Visual Studio 11 and go to the New Project menu. If you are familiar with this menu in Visual Studio 2010, you will quickly notice some differences.

First, you will notice you have a lot less choices. I really like this change. I always found it confusing that there was many project types that really just equated to a SharePoint Project Item that you would create in any project using the New Item menu. I always used the blank SharePoint project and we now refer to this simply as a SharePoint 2010 Project. Be sure and change the framework to .NET Framework 3.5 as it default to .NET Framework 4.5 by default. One other change you might notice is that there are no longer any SharePoint 2007 projects available.

Create a SharePoint 2010 Project and then be sure and check Sandboxed Solution since we are going to the cloud. Go ahead and create a new Visual Web Part next. Now you might be thinking, that you can’t do Visual Web Parts in sandboxed solutions. In the past, we had to rely on tools from the community to make this happen. Now Visual Studio 11 supports Visual Web Parts out-of-the-box. We’ll talk more about these in my next post. Drag a label or whatever ASP.NET controls you want onto the design surface and create your “Hello, World!” text. When you are done, click Build. Don’t bother deploying it though.

Now we want to publish this solution to SharePoint Online. Visual Studio 11 actually makes it quite easy. Right click on the project and click Publish. This brings up a new dialog prompting you for the URL to your site. You can specify another SharePoint 2010 server or in our case we’ll specify my URL to a site collection in SPO.

Once you click the Publish button, it will take a few seconds to connect and finally it will prompt you for authentication.

Enter your credentials and the solution will publish soon. When it is done, you will be taken to the Solutions gallery. At this point, you need to select the solution and click the Activate button to make your solution available.

At this point, you can edit any page and find your web part in the list. I just added it to the home page of the site as you can see in the screenshot below.

I’ve talked about how to deploy solutions to SharePoint Online in the past and this makes things much easier. This will definitely reduce development time. We still have to throw our solution “over the fence”, but at least it’s somewhat automated now. I can only hope for debugging in the cloud some day. :)

One thing to note is that you still have to do the development on a machine that has SharePoint installed. I even tried to trick it, but it wouldn’t cooperate.

Now, you might be thinking this is great and wondering if you should switch to Visual Studio 11 for SharePoint Online development. At this point, I don’t see any huge risk in doing that, but don’t blame me if things blow up. :) Make use of source control and backups and you should be able to correct anything that VS11 manages to break. When you are using source control, I see the worst that could happen is that you might have to go back a version or two in source control. For the extreme pessimist, I am sure worse could happen, but you always take that risk with pre-release software.

If you haven’t checked out Visual Studio 11 yet, head over to the developer site where you can get the download link and find out everything that’s new.

Using search to find recently modified files in SharePoint 2010

CoreyRoth — Thu, 08 Dec 2011 20:15:24 GMT

Last week, I posted about how we can extend CoreResultsWebPart to show documents created by the current user. Using this same technique, we can also use search to find recently modified documents. If you are a long time follower of my blog, you might remember that I posted how to do with using the Wildcard Search Web Part in SharePoint 2007. In an effort to keep posts updated, I thought I would post a follow up on how we can do the same thing in SharePoint 2010. Since the CoreResultWebPart has changed quite a bit, the solution is quite a bit cleaner and still only requires two lines of code. Again, we are going to create a web part that inherits from CoreResultsWebPart as described in my Wildcard Search Web Part for SharePoint 2010 post.

The first thing we need to do is change the QueryNumber. By default it is set to Query1 (or UserQuery back in 2007) which meant that it was expecting input from the user. In this case, I just change it to Query2.

this.QueryNumber = QueryId.Query2;

Then we just need to construct a query using the Write keyword. I’ve explained its use before in my handy keywords post. It’s syntax is usually something like this. Note that there are no spaces anywhere in the string below.

Write>=”12/1/2011”

Of course this would hard code the date and we don’t want that. So what I do instead is use DateAdd and subtract a number of days. In my case, I want to show all documents from the last seven days. We assign this query to the FixedQuery property. Here is what it looks like.

this.FixedQuery = string.Format("Write>=\"{0}\"", DateTime.Today.AddDays(-7));

Compile your code and deploy it and then you are good to go. Just use this web part in lieu of the regularCoreResultsWebPart. Here’s what it looks like on my page.

That’s all there is to it. One addition, you might want to make to your code is to allow the number of days to be user configurable. You can easily make a web part property that allows the user to specify the number of days.

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.

Adding missing web parts with the PortalLayouts feature after SharePoint 2007 upgrade

CoreyRoth — Tue, 25 Jan 2011 22:36:16 GMT

One thing I find annoying after attaching a SharePoint 2007 content database is that several of the new cool SharePoint 2010 web parts are simply not present on your upgraded site. This includes the new social web parts such as the Tag Cloud, Organization Browser, and Note Board. On an upgraded site, you may find that your Social Collaboration category looks like this:

I have talked about this in the past, but I’ve changed how I resolve the issue so I thought I would share a quick update. Before we begin, it’s a good idea to understand what has happened. In SharePoint 2007, you had site templates and they likely activated a feature called PortalLayouts. This feature still exists in SharePoint 2010, but it has changed. Specifically the file that we are interested in, webpartdwpfiles.xml, activates different web parts now.

Excuse me for the large display of XML here, but I think seeing it will make more sense. In SharePoint 2007, webpartdwpfiles.xml contained the following XML. Each File element installs a specific web part into the web parts gallery.

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Module Name="WebPartPopulation" Url="_catalogs/wp" Path="dwp" RootWebOnly="TRUE">
    <File Url="siteFramer.dwp" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,ContentRollupWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Miscellaneous;#" />
    </File>
    <File Url="owa.dwp" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,OutlookWebAccessWebPartGroup;"></Property>
    </File>
    <File Url="owainbox.dwp" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,OutlookWebAccessWebPartGroup;"></Property>
    </File>
    <File Url="owacalendar.dwp" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,OutlookWebAccessWebPartGroup;"></Property>
    </File>
    <File Url="owatasks.dwp" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,OutlookWebAccessWebPartGroup;"></Property>
    </File>
    <File Url="owacontacts.dwp" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,OutlookWebAccessWebPartGroup;"></Property>
    </File>
    <File Url="contactwp.dwp" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,MiscellaneousWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Miscellaneous;#" />
    </File>
    <File Url="AdvancedSearchBox.dwp" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,SearchWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Search;#" />
    </File>
    <File Url="PeopleSearchBox.dwp" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,SearchWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Search;#" />
    </File>
    <File Url="SearchBox.dwp" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,SearchWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Search;#" />
    </File>
    <File Url="SearchCoreResults.webpart" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,SearchWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Search;#" />
    </File>
    <File Url="SearchHighConfidence.webpart" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,SearchWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Search;#" />
    </File>
    <File Url="searchsummary.dwp" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,SearchWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Search;#" />
    </File>
    <File Url="searchstats.dwp" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,SearchWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Search;#" />
    </File>
    <File Url="searchpaging.dwp" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,SearchWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Search;#" />
    </File>
    <File Url="PeopleSearchCoreResults.webpart" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,SearchWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Search;#" />
    </File>
    <File Url="SearchBestBets.webpart" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,SearchWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Search;#" />
    </File>
    <File Url="SearchActionLinks.webpart" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,SearchWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Search;#" />
    </File>
    <File Url="CategoryWebPart.webpart" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,SiteDirectoryWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Site Directory;#" />
    </File>
    <File Url="CategoryResultsWebPart.webpart" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,SiteDirectoryWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Site Directory;#" />
    </File>
    <File Url="TopSitesWebPart.webpart" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,SiteDirectoryWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Site Directory;#" />
    </File>
    <File Url="ThisWeekInPictures.DWP" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,DefaultWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Default;#"/>
    </File>
    <File Url="TasksAndTools.webpart" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,DefaultWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Default;#"/>
    </File>
    <File Url="RssViewer.webpart" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,DefaultWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Default;#"/>
    </File>
    <File Url="TopAnswer.webpart" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,SearchWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Search;#" />
    </File>
    <File Url="SummaryResults.webpart" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,SearchWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Search;#" />
    </File>
  </Module>
</Elements>

Here is what the file looks like in SharePoint 2010.

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Module Name="WebPartPopulation" Url="_catalogs/wp" Path="dwp" RootWebOnly="TRUE">
    <File Url="siteFramer.dwp" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,ContentRollupWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Miscellaneous;#" />
    </File>
    <File Url="owa.dwp" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,MyInformationWebPartGroup;"></Property>
    </File>
    <File Url="owainbox.dwp" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,MyInformationWebPartGroup;"></Property>
    </File>
    <File Url="owacalendar.dwp" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,MyInformationWebPartGroup;"></Property>
    </File>
    <File Url="owatasks.dwp" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,MyInformationWebPartGroup;"></Property>
    </File>
    <File Url="owacontacts.dwp" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:spscore,MyInformationWebPartGroup;"></Property>
    </File>
    <File Url="contactwp.dwp" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:core,PeopleWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Miscellaneous;#" />
    </File>
    <File Url="AdvancedSearchBox.dwp" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:Microsoft.Office.Server.Search,SearchWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Search;#" />
    </File>
    <File Url="PeopleSearchBox.dwp" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:Microsoft.Office.Server.Search,SearchWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Search;#" />
    </File>
    <File Url="SearchBox.dwp" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:Microsoft.Office.Server.Search,SearchWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Search;#" />
    </File>
    <File Url="SearchCoreResults.webpart" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:Microsoft.Office.Server.Search,SearchWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Search;#" />
    </File>
    <File Url="searchsummary.dwp" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:Microsoft.Office.Server.Search,SearchWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Search;#" />
    </File>
    <File Url="searchstats.dwp" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:Microsoft.Office.Server.Search,SearchWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Search;#" />
    </File>
    <File Url="searchpaging.dwp" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:Microsoft.Office.Server.Search,SearchWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Search;#" />
    </File>
    <File Url="PeopleSearchCoreResults.webpart" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:Microsoft.Office.Server.Search,SearchWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Search;#" />
    </File>
    <File Url="SearchBestBets.webpart" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:Microsoft.Office.Server.Search,SearchWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Search;#" />
    </File>
    <File Url="SearchActionLinks.webpart" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:Microsoft.Office.Server.Search,SearchWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Search;#" />
    </File>
    <File Url="TopAnswer.webpart" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:Microsoft.Office.Server.Search,SearchWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Search;#" />
    </File>
    <File Url="SummaryResults.webpart" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:Microsoft.Office.Server.Search,SearchWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Search;#" />
    </File>
    <File Url="Refinement.webpart" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:Microsoft.Office.Server.Search,SearchWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Search;#" />
    </File>
    <File Url="PeopleRefinement.webpart" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:Microsoft.Office.Server.Search,SearchWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Search;#" />
    </File>
    <File Url="QuerySuggestions.webpart" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:Microsoft.Office.Server.Search,SearchWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Search;#" />
    </File>
    <File Url="CategoryWebPart.webpart" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:core,ContentRollupWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Site Directory;#" />
    </File>
    <File Url="CategoryResultsWebPart.webpart" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:core,ContentRollupWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Site Directory;#" />
    </File>
    <File Url="RssViewer.webpart" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:core,ContentRollupWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Default;#"/>
    </File>
    <File Url="TagCloud.dwp" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:core,PeopleWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Default;#"/>
    </File>
    <File Url="SocialComment.dwp" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:core,PeopleWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Default;#"/>
    </File>
    <File Url="ProfileBrowser.dwp" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:core,PeopleWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Default;#"/>
    </File>
    <File Url="DualChineseSearch.dwp" Type="GhostableInLibrary">
      <Property Name="Group" Value="$Resources:Microsoft.Office.Server.Search,SearchWebPartGroup;"></Property>
      <Property Name="QuickAddGroups" Value=";#Search;#" />
    </File>
  </Module>
</Elements> 

If you look at some of the differences, you’ll notice that several web parts have been added in 2010, but several have also been removed. Web Parts that have been added include:

Tag Cloud (TagCloud.dwp)
Note Board (SocialComment.dwp)
Organization Browser (ProfileBrowser.dwp)
Dual Chinese Search (DualChineseSearch.dwp)
Refinement Panel (Refinement.dwp)
People Refinement Panel (PeopleRefinement.dwp)

Web Parts that have been removed in SharePoint 2010 include:

This Week in Pictures (ThisWeekInPictures.dwp)
Top Sites (TopSitesWebPart.webpart)
I need to… (TaskAndTools.webpart)

When you do an upgrade, you’ll still have your removed web parts in the gallery. However, if you are on a new installation and want one of those old web parts, you’ll have to do a little work. From what I have read, you can export the .webpart or .dwp file of the web part and upload it to the solution gallery manually on your new server. It appears the underlying code is still present in the assemblies, just the web parts definitions have been removed from the web part gallery.

However, we’re interested in adding the new SharePoint 2010 web parts to the site collection’s web part gallery. You can manually upload them if you so choose. However, I’m not really a fan of that solution, but it will work in a pinch. Instead my solution now is to activate the PortalLayouts feature again. The feature is hidden, so your best bet to do this is with PowerShell. We do this with the Enable-SPFeature cmdlet. Since the feature was technically already activated in SharePoint 2007, we have to use the –force parameter. Here is the complete command for a root site located at http://sp2010.

Enable-SPFeature –Identity PortalLayouts –url http://sp2010 –force

If the command worked successfully, you should receive no errors and another command prompt. At this point, you can add your new web parts to an existing page. You should see three new ones in the Social section as shown.

I have not encountered any issues by reactivating this feature yet. It works for me and hopefully it works for you too. If you are missing web parts, try it out and see how it works for you.

Missing Tag Cloud Web Part (and other Social Web Parts) after SharePoint 2010 Upgrade

CoreyRoth — Fri, 06 Aug 2010 15:23:55 GMT

I noticed this little issue after doing my last SharePoint 2010 upgrade. The client was a fan of the Tag Cloud Web Part on his My Site and wanted to bring that functionality onto one of his team sites. I figured this would be no problem, so we went to the Team Site, clicked Add New Web Part, looked under Social Collaboration only to find the Tag Cloud missing from the list. In fact, Tag Cloud was not the only thing missing. Contact Details, Note Board, and Organization Browser were also missing. I checked the web part gallery and there was no sign of the Tag Cloud present. I verified that the SharePoint Standard and Enterprise features are activated, but still no sign of it.

At this point, I decide to do some digging. I wanted to find out which feature installed this web part. After looking at a working SharePoint 2010 server, I determined that the web part comes from the file TagCloud.dwp (a version 2 web part schema on a brand new web part? Really?). I head to the 14 hive and search the features folder and determine that, this web part is deployed by the PortalLayouts and MySiteLayouts hidden features. Then it all makes since (well sort of). Since I upgraded this site from MOSS 2007, the new version of PortalLayouts has not activated on my site collection.

At this point, I had a decision to make. I could force the PortalLayouts feature to activate again or I could leave well enough alone and just manually upload the .dwp file into the Web Parts gallery. I went with the latter so I grabbed TagCloud.dwp from 14\TEMPLATE\FEATURES\PortalLayouts\DWP and uploaded it to the web part gallery and the web part worked just fine. I wasn’t sure what the other unintended results might be on the site collection had I force activated the PortalLayouts feature again so this seemed like the right decision. If you are interested in the other web parts, you can upload contactwp.dwp, profilebrowser.dwp, and socialcomment.dwp to your gallery as well. There may be other web parts missing too, but I think this is it.

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.

Impress the Boss with the SharePoint 2010 Chart Web Part

CoreyRoth — Wed, 24 Feb 2010 17:09:12 GMT

Let’s face it. Nowadays, management absolutely loves BI. Especially when there are lots of pretty charts and graphs. The thing is I’m not a BI guy. Cubes scare me to death. Luckily, there is the new snazzy Chart Web Part in SharePoint 2010 that gives you some BI like capabilities. It doesn’t allow you to drill down and pivot and do all that fancy stuff, but it does let you make some nice graphs and charts that any ordinary developer can do.

To get started, first you need an Enterprise version of SharePoint 2010. Unfortunately, I used the key that was later determined to be the wrong one which led me to reinstall SharePoint with a new key. If you don’t have any Enterprise options available, then you will be reinstalling. Assuming, you do have an Enterprise key, you then need to activate the SharePoint Server Enterprise Site Collection Features.

This adds the chart web part (among other things). Then edit any page and add a Chart Web Part. You can find it under Miscellaneous as of Beta 2 (they may have found it a new home in later versions).

When you add it to the page, it uses some dummy data and displays a simple bar chart.

At this point, you might be asking yourself “What kind of data can I bind this to?”. By clicking Data & Appearance, you will see the following screen which leads you to links to customize the appearance or bind to data.

We’ll start by going to Connect Chat To Data. Look at these great options we have to choose from.

We can connect to another web part, a list, an external content type (looks like they need to update the BDC wording they have there), and to Excel Services. I tried going straight to an external content type, but I got a yellow screen. Apparently that is broken on my version, but I’m sure it will work in RTM. There is a work around though. You can pick an external list using the Connect to a List option. This is exactly what I am going to do.

Remember that external list I created on my BCS blog post? I’m going to use that list and extend it some. What I did is I created a new custom list to contain Monthly Sales information. I used an External Data field to allow the user to pick a product from the external content type and enter in some sales data in a field.

This is the list we are going to use on our chart. On the next step of the wizard, we are allowed to pick a list. Note that it also allows you to choose other sites in the collection as well.

The next step allows you to filter your data first if you are so inclined.

The Chart Web Part has a ton of configurable options. On this last step is where you will start seeing some of them. The main thing to set here is your X and Y fields. You can also specify something to group by as well.

Once you finish this last step, you’ll get something that looks like this.

So, what we have here is a chart bound to data coming from a database (via external content type) and a SharePoint list. Pretty cool, right? I think so. It gets better though. What if your boss doesn’t like bar charts? No problem. There are tons of chart types to choose from. Just click on Data & Appearance again and then Customize Your Chart. Look at all of these built in chart types you have.

On the next step, you can further customize the chart you choose. It has some nice pre-built color themes and you can customize the size and what not. It also gives you a live preview as you change settings.

Here is what my new chart looks like.

You can customize things even more by going to Advanced Properties. It would probably take me a week to show you everything that this web part does, so I recommend you go try it out for yourself. The charts and graphs this thing produces are so cool, you should have no issue getting your boss to sign off on the Enterprise license. :)

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.

Troubleshooting Sandboxed Solutions in SharePoint 2010

CoreyRoth — Mon, 30 Nov 2009 19:08:00 GMT

I have a talk coming up on Code Access Security at SharePoint Saturday Kansas City next month so I have been investigating sandboxed solutions quite a bit. After all, sandboxed solutions are just another flavor of using CAS with some additional things thrown in. However, after I got my SharePoint server installed and configured, I found that sandboxed solutions were not working. When I configured my solution to use the sandbox and tried to deploy it, I got the following error.

Error occurred in deployment step 'Activate Features': Cannot start service SPUserCodeV4 on computer 'servername'.

I found that to be odd, so I decided to do some looking around. I ended up in the Windows Services MMC snapin and found that the service called Windows SharePoint Services UserCode Host v4 was in fact set to disabled. I changed this to automatic and started the service up. I tried to deploy again, but unfortunately things still weren’t working. Here is the error I got this time.

Error occurred in deployment step 'Activate Features': This feature cannot be activated at this time. The contents of the feature's solution requires the Solution Sandbox service to be running.

This one took a little bit more digging, but I ended up going to Central Administration and looking at the Services on Server page. I thought what I needed would be under Service Applications, but that was not the case. I took a look at Services on Server and quickly discovered that the Microsoft SharePoint Foundation User Code Service had not been started. I started the service and then I tried to deploy again and the errors went away and my sandboxed web part worked as expected. I’m not sure why neither of these started. It could be because I don’t have enough memory allocated to the virtual machine or maybe it’s always disabled by default. Anyhow, be sure and check these two things before you try to work in the sandbox.

UPDATE: @MSwannMSFT confirmed for me that this is by design. It’s disabled for performance and security since it spins up three new processes.