Corey Roth [MVP] : SharePoint 2010, WebPart, SharePoint Online

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.

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.