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

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.

Deploying a Web Part with Code Access Security in Visual Studio 2010 (SP2010)

CoreyRoth — Fri, 20 Nov 2009 20:38:00 GMT

By now, you have heard about how the SharePoint 2010 development experience has been improved. We can easily deploy web parts and other code without having to manually manipulate any XML files. What about under partial trust though? Many of you that know me know that I have pushed using Code Access Security quite a bit through a series of blog posts and talks. So it would be irresponsible of me not to talk about how we can do that in Visual Studio 2010. The good news is that it is a lot easier.

Let’s start by creating a new SharePoint project in Visual Studio 2010 and creating a new Web Part project item. In this case we are talking about deploying a Farm Solution, not a Sandboxed Solution. Note: we are going to talk about a traditional web part today, and not a Visual Web Part. Visual Web Parts are simply not supposed under partial trust. More on that later below. My web part has some simple code which uses ASP.NET and also hits the SharePoint object model to display the title of the site in a label. Here is what the code looks like.

protected override void CreateChildControls()
{
    Controls.Add(new Label(){Text = "<div>My Cool Web Part!</div>"});
    Controls.Add(new Label() { Text = string.Format("Site Title: {0}", SPContext.Current.Web.Title) });
 
    base.CreateChildControls();
}

When you create a new project, it deploys to the GAC by default. We start by changing this on the project properties.

This effectively changes the DeploymentTarget attribute on Assembly element in the Manifest.xml. At this point, you may be asking. “Sweet, is that it? Does it take care of the CAS policy for me?” The answer to that of course is “No.” However, it is quite easy to add it. Let’s see what happens if we try to deploy it as is. I’ll just hit F5 to start debugging. I then add my web part to any existing page, and I immediately get hit with the following in Visual Studio.

System.Security.SecurityException: Request for the permission of type 'Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' failed.

Luckily we know how to fix this. Hopefully, this will also help new developers when they get this error in the future and aren’t sure what to do. We need to grant permissions to this assembly to use the object model as well as a few other things. We’ll start by using a standard set of IPermission elements that I have used in past posts. This gives me basic ASP.NET, SharePoint object model, and Security permissions.

<CodeAccessSecurity>
  <PolicyItem>
    <PermissionSet class="NamedPermissionSet" version="1" Description="Permission set for VisualWebPartProject1.">
      <IPermission class="AspNetHostingPermission" version="1" Level="Minimal" />
      <IPermission class="SecurityPermission" version="1" Flags="Execution,ControlPrincipal,ControlAppDomain,ControlDomainPolicy,ControlEvidence,ControlThread" />
      <IPermission class="Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
                   version="1" ObjectModel="True"  />
      <IPermission class="System.Security.Permissions.EnvironmentPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Read="UserName" />
      <IPermission class="System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Read="$AppDir$" Write="$AppDir$" Append="$AppDir$" PathDiscovery="$AppDir$" />
    </PermissionSet>
    <Assemblies>
      <Assembly Name="VisualWebPartProject1"  />
    </Assemblies>
  </PolicyItem>
</CodeAccessSecurity>

You can use this in your code almost exactly but two small changes are required. First, you need to change your assembly name to whatever you have called yours. Secondly, if you look at that SharePointPermission, you’ll notice it says version 12.0.0.0. We need to change this to 14.0.0.0 since we are working with SharePoint 2010 now. Adding this to your package is quite easy. In the Solution Explorer, locate Package and then Package.package and open it. This will bring open the package designer. Click on the Manifest tab at the bottom and then expand Edit Options. The way this works is that you can paste any additional elements here and it will merge your items with the ones it automatically generates. Here is what I would paste in.

<?xml version="1.0" encoding="utf-8"?>
<Solution xmlns="http://schemas.microsoft.com/sharepoint/">
  <CodeAccessSecurity>
    <PolicyItem>
      <PermissionSet class="NamedPermissionSet" version="1" Description="Permission set for VisualWebPartProject1.">
        <IPermission class="AspNetHostingPermission" version="1" Level="Minimal" />
        <IPermission class="SecurityPermission" version="1" Flags="Execution,ControlPrincipal,ControlAppDomain,ControlDomainPolicy,ControlEvidence,ControlThread" />
        <IPermission class="Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
                     version="1" ObjectModel="True"  />
        <IPermission class="System.Security.Permissions.EnvironmentPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Read="UserName" />
        <IPermission class="System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Read="$AppDir$;C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\CONTROLTEMPLATES\VisualWebPartProject1" Write="$AppDir$" Append="$AppDir$" PathDiscovery="$AppDir$" />
      </PermissionSet>
      <Assemblies>
        <Assembly Name="VisualWebPartProject1"  />
      </Assemblies>
    </PolicyItem>
  </CodeAccessSecurity>
</Solution>

Here is what it would look like on the screen.

If everything is correct, you will see the merged result up top. If there is an error in your XML, you will also see it there. Now let’s deploy the solution and see if we can add the web part to an existing page.

Unfortunately, this is the error we get and it actually gives us good information. We simply forgot to add the APTCA attribute (or AllowPartiallyTrustedCallers). Just open your AssmeblyInfo.cs file and add the following line.

[assembly: AllowPartiallyTrustedCallers()]

Redeploy your solution and try to add your web part again. If all goes well, you will have a lovely web part on the screen that looks like this.

With the above set of CAS policies, you can probably get most of the code you want to do to work. I mentioned Visual Web Parts above. Here is the issue I am currently seeing. If you remember my post on the Visual Web Part, you will know that this is just a web part with a Page.LoadControl() method calling a User Control (.ascx). Page.LoadControl requires a ton of permissions and I haven’t been able to figure them out. This means, it simply will not work. I posted something to the forums about it. Paul Andrew was nice enough to respond to my post and state that Page.LoadControl simply will not function under partial trust. It has a check in it to verify that it is not running under partial trust. He also goes on to explain this is why you can’t use Visual Web Parts in sandboxed solutions.

This may seem like a lot of steps, but really I just posted a lot of pictures. Trust me it’s a lot fewer steps than it was before in MOSS 2007. Just look at my old post if you don’t believe me. Now, you might ask why would I do this instead of a Sandboxed solution? Sandboxed solutions are severely limited on what they can do with the SharePoint object model. By default, the CAS policy that defines them can’t even connect to a database. I can specify at a per assembly level here what each one can do. That is a big advantage.

Introducing the Visual Web Part in SharePoint 2010

CoreyRoth — Tue, 20 Oct 2009 21:38:19 GMT

You might have seen that there is a new designer for working with web parts in Visual Studio 2010. This is actually, not quite the case, so I thought I would share with you how it actually works. When you use the Visual Web Part SPI (SharePoint Project Item), it will create a number of files for you: a .cs file, a .webpart file, an elements.xml file, and a .ascx file. That’s right, it creates an ASP.NET user control. Now, the Visual Studio interface does a nice job of grouping all of the files together. When you open the designer on the web part, you in fact just open the designer for the user control.

So now you might be thinking, how does this work? Well no SharePoint can’t host user controls directly still. In fact all it does is create a simple web part with a Page.LoadControl() method pointing at our user control. This in fact is the same method we’ve been using for years to get user controls into SharePoint. I don’t really see this as an issue though, since Visual Studio does a great job making it painless to deploy these now and use them inside SharePoint.