No Free Time

Because my therapist says I need to let things out

Archive for the ‘moss 2007’ Category

Create a list in a SharePoint site programmatically

Posted by andrewmyhre on March 21, 2009

Creating a list programmatically might be handy when you need to do this in a web part or, if you’re in the situation I was in today, you need to create a list where the template is not available on the Create page.

In my case I had a Collaboration site but I needed to create a Discussion Board – impossible using the SharePoint UI. How to get around this?

The first solution that occurred to me, and what I assumed I HAD to do, was to create a custom site definition. I had no idea how to go about doing this so this was a daunting prospect. But it occurred to me that, ultimately, I’ll only need to do this one time, maybe twice, and my users will never do this. So why go to all that trouble when the purpose of a site definition is to create a repeatable story for your end users? All I needed was a one shot hack.

So I remembered the SharePoint object model, and wrote an app. This app takes three arguments – Site URL, List Name, List Template ID. I used it to create a new discussion board in my site, it’s repeatable enough for my purposes, and it took me 5 minutes to write.

The code is provided below, but I want to hit home the point of this post – SharePoint is not as difficult as you think. There is always a simple way to do what you want to do. The difficulty is remembering to think outside the UI. I used to think that where SharePoint build was concerned I’d have to get used to telling customers ‘No’ but, as it turns out, that’s not that case at all.

CreateList.exe Source

1 using System;

2 using System.Collections.Generic;

3 using System.Linq;

4 using System.Text;

5 using Microsoft.SharePoint;

6

7 namespace CreateList

8 {

9 class Program

10 {

11 static void Main(string[] args)

12 {

13 if (args.Length == 0)

14 {

15 PrintListTemplates();

16 return;

17 }

18

19 bool validArgs = true;

20 if (!Uri.IsWellFormedUriString(args[0], UriKind.Absolute))

21 {

22 Console.WriteLine(“Arg 0 must be an absolute Sharepoint site URL e.g: http://mysite.com”);

23 validArgs = false;

24 }

25

26 int templateId=0;

27 if (!int.TryParse(args[2], out templateId))

28 {

29 Console.WriteLine(“Arg 2 must be a valid list template id from the following list:”);

30 validArgs = false;

31 PrintListTemplates();

32 }

33 if (!validArgs)

34 {

35 Console.WriteLine(“Invoke with no arguments to get a list of available SharePoint List templates”);

36 return;

37 }

38

39

40 Uri siteUrl = new Uri(args[0]);

41 string listName = args[1];

42

43 AddListToSite(siteUrl, listName, templateId);

44 }

45

46 private static void AddListToSite(Uri siteUrl, string listName, int SPListTemplateTypeId)

47 {

48 using (SPSite site = new SPSite(string.Format(“{0}”, siteUrl)))

49 {

50 SPWeb web = site.OpenWeb();

51 Guid listGuid = web.Lists.Add(listName, “”, (SPListTemplateType)SPListTemplateTypeId);

52 SPList list = web.Lists.GetList(listGuid, true);

53 }

54 }

55

56 private static void PrintListTemplates()

57 {

58 string[] typeNames = System.Enum.GetNames(typeof(SPListTemplateType));

59 Array typeValues = System.Enum.GetValues(typeof(SPListTemplateType));

60

61 int j = 0;

62

63 foreach (int i in typeValues)

64 {

65 Console.WriteLine(typeNames[j++].ToString() + ” “ + i.ToString());

66 }

67 }

68 }

69 }

Posted in .net, moss 2007, sharepoint | Tagged: , , | 1 Comment »

The Sharepoint Development Experience – Part 1

Posted by andrewmyhre on January 15, 2009

I want to describe the development process involved in creating a web part for a Sharepoint site, hopefully to dispel the belief that it’s difficult and time-consuming. What I want to demonstrate is that it’s actually very simple – no more difficult than creating a custom control in ASP.Net 2.0 – provided you have set up your development infrastructure correctly.

Development infrastructure is where most of the pain associated with Sharepoint development really exists, which is why following this article I’m going to continue with a series describing how you can set up the various parts of your infrastructure to enable friction-free development.

This post, however, will show you exactly how friction-free it can be. I’m going to show the steps to build a basic web part and deploy it to your sharepoint solution in a repeatable and reversible way. I’ll also give a tour of how to customise the look-and-feel of a Sharepoint website using the Sharepoint designer. The purpose of this is show to illustrate that developing with Sharepoint isn’t really that much different to developing for a standard ASP.Net 2.0-based website.

Development

Watch me create and deploy a brand new web part to a Sharepoint server:

1. This is my out of the box Publishing Site template
01 

2. I’m going to add a web part to my site by adding a new class to my visual studio project
02

3. My class must inherit from Microsoft.SharePoint.WebPartPages.WebPart. I’m going to override the Render method to make the web part output some text. Note how similar this is to an ASP.Net custom control.
03

4.  I build the project. A post-build step creates a CAB file which can be deployed to Sharepoint. This packages up my new features/webparts so that I can manage their usage within Sharepoint and easily repeat/reverse this deployment process.
04

5.  I run a script to deploy the CAB file to Sharepoint. 
05 

6. In Sharepoint I add the Web Part to a page. If I haven’t deployed this web part before I need to Import the web part from the Site Settings menu first.
06 

7. And there it is!
07 

This development process is so simple and repeatable, it’s just like a standard ASP.Net website. What’s more when I set up source-control for my visual studio solution I can set up a continuous integration environment to automatically deploy my changes for me.

Layouts

Now I’m going to change the layout for this page. Most developers seem to believe this is an almost impossible task, or at least much more painful than editing a regular ASP.Net 2.0 Web Forms page. Well, watch:

1. My page layout
08 

2. I open up Sharepoint Designer and browse to the page I want to edit and double click. Sharepoint Designer asks me if I want to edit the content for the page or the layout for the page. I select layout. Here’s what I see:

09

There are a lot of controls on the page. Most of them have the prefix SharePointWebControls, so we can pretty easily see what they’re doing and we don’t have to be afraid. Otherwise this is just like a standard ASP.Net Web Forms page – it has stuff inside ContentPlaceHolder controls. Sharepoint assigns this page layout a master page at runtime.

3. See those ugly tables in the PlaceHolderMain ContentPlaceholderControl? I’m going to change those to divs:

 10

4. And now I’m going to edit the master page for this page layout. I know that the master page I want to edit happens to be BlueBand.master, because I chose it within the SharePoint Site Settings menu. And I also know that all master pages can be found in /catalog/masterpage in SharePoint Designer. I’ll change the tables there to divs too.
12 

5. I check-in the changes to these files (SharePoint automatically provides versioning on these files because they’re actually in the SharePoint database – more on that in another post) and reload my site homepage:
13 

Not such a visually impressive example, I know, but I just wanted to demonstrate that editing a SharePoint website isn’t really that different to building an ASP.Net website, and it’s no more difficult.

In future posts I’m going to walk through how to set up the infrastructure to be able to enjoy the development experience I demonstrated in the first section, and I also hope to demonstrate some ways to make layout editing more enjoyable, like by removing as much of the .Net cruft as possible and make your pages generate something more like semantic markup.

Posted in .net, moss 2007, sharepoint | 2 Comments »

Membership Provider error: A connection was successfully established with the server, but then an error occurred during the login process. (provider: Shared Memory Provider, error: 0 – No process is on the other end of the pipe

Posted by andrewmyhre on March 28, 2008

Got this obscure error today when setting up a membership provider. I was setting up an ASP.Net Sql Membership Provider for Sharepoint 2007.

First I ran aspnet_regsql.exe for the SQL Express database behind the Sharepoint install, creating a new database in the process just for the ASPNet membership provider data. I then set up a connection string in the web.config for the sharepoint application, and added the <membership> and <roleManager> data to the web.config also. Trying to open the sharepoint site in a browser then yielded the error:

“An unexpected error has occurred. “

To properly diagnose the issue I created a new, blank ASP.Net website, and copied the connectionStrings, membership and roleManager config settings into the web.config for the new site. Then I opened the ASP.Net Administration Tool, and clicked the Security section link, which gave me a much more informative description of the error:

Default Membership Provider could not be found. (C:\TestWebsite\web.config line 17)

Nice! So I added the defaultProvider attribute to the membership element. Next, though, I got a weird error:

“A connection was successfully established with the server, but then an error occurred during the login process. (provider: Shared Memory Provider, error: 0 – No process is on the other end of the pipe.)”

Weird. Luckily though, my sixth, or perhaps seventh sense told me it was probably an authentication issue with the database. Sure enough, when I replaced the User ID and Password parts of the connection string with “Integrated Security=true”, the administration tool started working without problems. Copying the changes back into the Sharepoint web.config proved that I’d fixed the issue.

Posted in moss 2007 | Tagged: , , | 2 Comments »