Corey Roth [MVP] : Visual Studio 2010, WebPart, SharePoint 2010

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

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

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

Beginning SharePoint 2010 Development for ASP.NET Developers Slide Deck

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

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

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

Follow me on twitter @coreyroth.

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

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

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

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

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

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

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

using System;

using System.ComponentModel;

using System.Web;

using System.Web.UI;

using System.Web.UI.WebControls;

using System.Web.UI.WebControls.WebParts;

using Microsoft.SharePoint;

using Microsoft.SharePoint.WebControls;

namespace SharePointOnlineProject3.HelloCloudWebPart

{

    [ToolboxItemAttribute(false)]

    public class HelloCloudWebPart : WebPart

    {

        protected override void CreateChildControls()

        {

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

        }

    }

}

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

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

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

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

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

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

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.

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.