SharePoint Foundation 2010 Web Parts – The Way Things Should Have Been

Have you ever uttered an obscenity when you tried to build a web part for SharePoint 2007? How about for SharePoint 2003? Wasn’t that just ridiculous? Well on first review, your vocabulary may be taking a turn for the better; This really is easy.

The one thing that hasn’t gotten any better is the propensity for the providers of “How-To” guides at Microsoft to booger things up while we struggle with these new concepts.

For example, anybody that can make heads or tails out of this ought to work for the Franklin Mint. As I read it, the file names vary from step to step and the code includes the fancy left and right side quotation marks that blow up your .cs pages. So I went looking for another one.

Then I found this one that was much better but still has at least one “gotcha.” It seems that the author neglected to properly modify his name space in his sample code and that will blow up your build. This gives us a good chance to try to figure our what his or her  problem is.

Recall that we’re running SharePoint Foundation on Windows 7 x64 VM, per our recent posts, and that we’ve installed VS2010 from the 90 day trial download version.

First, like I said, the create\build\deploy steps are a snap. In VS 2010, it’s File | New | Project and under the C# projects, select the SharePoint 2010 node, select the Visual Web Part and click OK. One thing to think about is where you put the solution. In Windows 7, if you put it in the C:\Sample Web Parts folder, you’ll have to do a silly Run As Administrator tap dance later to delete it. I chose to create and use a folder under my user name folder next to My Documents and check the Create directory for solution option. Then click OK.

Then, you get one of the cool new parts, it asks you for the site where you want to deploy\debug your web part. I created a blank sample site and used it. My Deploy as a Sandboxed Solution option was greyed out; not sure what to make of that. I just clicked Finish.

So my solution gets built and I’ve got a bunch of files and since I didn’t change the name in the previous step, in Solution Explorer, I’ve got a VisualWebPart1 node. I see it have a VisualWebPart1UserControl.ascx file under it which has a VisualWebPart1UserControl.ascx.cs file under it which has a VisualWebPart1UserControl.ascx.design file under it. Pretty Deep, no?.

Okay, on the .ascx file, right click and select View Design. The design page and the tool box open. In the toolbox, find the TreeView control under the Navigation section (Very Visio-like toolbox) and drag one onto the design. When the treeview control is selected in the design pane, its properties will show up in the properties pane at the bottom right of the VS workspace. Find the ID property and set it to siteStructure and then click Save. So far, so good.

Then we have to code the .cs page to populate the tree when the page loads. The guy\gal that wrote the post (here‘s another link to it)  just gives us the code with a convenient Copy Code link. Click the link. Back in your project, right click the .ascx.cs file and select view code. Click in the code somewhere and press CTRL-A | CTRL-V.

Notice the red squiggleys in two palces, both under the word siteStructure? Believe me, these guys get paid way more than me so they ought to know better.

Here’s the problem. The dude\dudette was obviously on his way back to Seattle back from Burning Man when he wrote this and he had Bonneville on his mind and wrote that into his namespace. Now I probably don’t understand namespaces as well as some of you, but I know:

BonnevilleTestBed.Bonneville <>VisualWebPartProject1.VisualWebPart1

The left side of that equation is the namespace cited in the .cs code we copied from the guy’s article. In addition, the code tries to build a partial class called:

BonnevilleUserControl

The left side of that equation is the namespace cited in the .cs code we copied from the guy’s article. If you right click on the .ascx.designer.cs page and select View Code, you’ll see that what we really need is a namespace called VisualWebPartProject1.VisualWebPart1 and a partial class named VisualWebpart1UserControl.

Copy those names from the .designer.cs page to the .ascx.cs page overwriting the silly Bonneville stuff. The red squiggleys go away. Press f5.

My Sample site comes up and sits there like it’s a SharePoint site which, of course it is, but it’s not doing anything. But, I can select Edit Page from the Site Actions menu and click Add a Web Part. In the Categories picker on the left, I select Custom and there’s my VisualWebPart1. I select it and the click Add and then click the Stop Editing button on the ribbon.

Since I used a blank site, there’s nothing under my Sample Site node but, as I add lists, libraries and subsites, they fall into my tree view just fine.

Now all we need to do it build a solution we can add to our SharePoint sites for real, not just in our debugger mode.

There’s a great expository on the process here written by our new best friend, Eric, at BinaryWave.com. He explains the advantages of the new process and an introduction to the steps we’ll take to deploy our new web part to a production farm.

Eric brings up a couple of great, new points, the first of which is conflict resolution. These are issues that arise when, for example, I deploy MyWebPart as a feature in a site where you’ve already deployed your MyWebPart. Conflict, Ouch! Let’s ignore this for now with a promise to explore these conflict resolution properties later.

Second, Eric tells us we’re really dealing with SPI’s (SharePoint Items.) These are the components that will be mashed into a solution for deployment. In our case we have one, VisualWebPart1. Eric tells us:

By default, all SPI’s in the project which are included in a Feature, along with any mapped folders, will be automatically added to the package.

That should work for us now since what we want is a package with our web part in it that we can add to our production environment. Where we’re headed is a file called package.package. See why I love this job? As we may already know, the steps are to bundle our SPI’s into a package, deploy the package as a solution on our target location and activate the features that bring our SPI’s to life while, at the same time, avoiding any conflict nastiness.

At this point Eric strays off into other objectives as we go looking for someone more on point, like our new best friend Belajar, here. He says right-click on our project name and select Package. I get a status bar indication that Package Succeeded and I get a VisualWebPartProject1.wsp in my project’s bin\debug folder.

So with the .wsp in hand, we need only to load it into our production portal. The best source for this info is our new best friend, ICC, who feeds us, here, the PowerShell routines that get this done for us.

I do the add-spsolution and that works fine.

Then, I try the install-spsolution and I get this silly error:

PS> install-spsolution -identity visualwebpartproject1.wsp -webapplication http://Jeffery -GACDeployment
Install-SPSolution : Admin SVC must be running in order to create deployment timer job.

That is where we go look at our Windows services and find the SharePoint 2010 Administration Service and start it. I recall setting it to Manual Start previously to conserve resources on the “Production” box. Then I have to go look in Central Administration to find the timer job that started but never ended. It’s in the list under Central Admin | Monitoring | Check job status. Now the status page is nice but with the way it pages, it’s kind of clumsy so I click on Job Definitions and found the VisualWebPartProject1 job and opened it and selected Delete. Then I went back to PowerShell and ran my install again. When it returns a PS prompt, I know something worked.

So I create a web part page to add my new web part to and it’s not there. Rats.

This leads me to the Web Part Gallery. It’s not there either.  More Rats.

Now this part is tricky. Notice, on the Web Part Gallery, up on the ribbon, you get a Library Tools set with a Documents and a Library option. Clicking on Documents we get a New Document option. Click it Baby!

 At the very bottom of the list, there’s our VisualWebProject1.VisualWebPart1.VisualWebPart1 web part. Drop an X in the box and click Populate Gallery back at the top of the page. That takes us back to the gallery with our new web part sitting there with a little SharePoint New flag next to it.

Go back to the web part page and click on the Add Web Part link. In the Miscellaneous group, we get the VisualWebPart1 option. Select it and click Add. Click the red X to stop editing and reload the page.

That has got to be the prettiest web part I have ever seen.

This is also where we’ll start our “Yay, It’s Friday” celebration. Have you seen Hoops and Yoyo’s “I Don’t Care Friday” routine?

-robot


Tags:

 
 
 

Comments are closed.