Archive

SharePoint Server 2010 gives the ability to identify the status of co-works or site members if they online , busy, or away by integrating with Presence Indicator Information concept. smart tag appears next to the user name to display the user status .

The key piece of information to make the presence work is the user’s SIP Address which is basically their IM address (This is not always the same as email address). When a users is either added to a site in SharePoint or has their profile imported, the SIP Address will be drawn from Active Directory which is where OCS stores it and placed into the SIP address field in either the user’s profile which will in turn synchronise down to the site’s local ‘User Information’ page.

The pawn is basically an IMG element which has “IMNRC(‘[user’s SIP Address]’)” for the onload function. This will user client-side script that is part of Office to load the presence pawn on the page.

The hyperlink on the user’s name is just a simple A element which redirects to “/_layouts/userdisp.aspx?ID=[User’s local user information list item ID]”. This userdisp.aspx page will then redirect to the user’s main profile page if they have a profile, otherwise it will display the basic information that the user information list item stores.

How to get the SIP Address?

Hopefully you’ll have spotted by now that the presence pawn relies on the user’s SIP Address. To get the SIP address you need to get the user’s User Information list item from the local site’s (SPWeb to be precise) SiteUserInfoList which is basically a hiddenSPList that is in every web.

There is a handy property to get you to this list called ‘SPWeb.SiteUserInfoList’. This will give you an SPList object which represents the User Information list. From here you just need to find the item that represents the user you wish to display. The best way to do this is via their ID (the ID of the list item) by calling SPWeb.SiteUserInfoList.GetItemById([int User’s ID]), however you can also use a variety of other methods which use SPQuery or match a specific field to a value.

In most scenarios, you may be getting the user information from a SPFieldUserValueCollection which is basically the field type that is used for ‘Person’ fields. If this is the case you can use SPFieldUserValue.LookupId to get the ID of the user’s User Information list item.

Putting it all together

This code sample is a method that accepts an SPFieldUserValueCollection and SPSite as inputs and returns back the HTML for displaying each entry in the SPFieldUserValueCollection with the presence pawn and link to their profile. This will be presented exactly as SharePoint presents it by default. This could be extended to use ALT tags in the IMG and A elements.

I then simply add the HTML to an HtmlWriter or in my case a TableCell.Text property to display it on screen.

I’ve take a few extra steps here by adding ID and alt tags and trying to make the code readable, but I’m sure you get the idea:

I was creating a SharePoint 2010 project in Visual Studio 2010. I’ve selected the Empty Project and then Add New Item and selected the Webpart item (not the Visual Webpart). After doing some coding, for some reason I’ve decided to change the original namespace that Visual Studio had created for me on the webpart class (.cs file). Then I did some more coding and time to test it. I right click on the project name and select Deploy (I love this new feature in VS2010). Everything goes smooth, package is deployed and everything seems fine. So I go to my SharePoint site, Edit the page, Insert a Webpart, select my new custom webpart and when I hit the Add button, for my surprise I got the error below.

And this is the second time around that this happened to me. The first time was a long time ago so I couldn’t remember why. Then it’s time to do some troubleshooting. I’ve verified that the .DLL file was in the GAC, I’ve checked the web.config file to make sure a <SafeControl> entry was created. Everything looks good. Then I check the webpart definintion file in the WebParts gallery and closely looking at the XML I’ve noticed that the namespace was not matching with my webpart class. The original namespace was still showing. So I went back to my Visual Studio project and I’ve opened the .webpart file (see below) that was created for me.

And for my surprise the original namespace was still showing up there. So if you change your namespace after you create a project in VS2010 make sure that in the .webpart file (see below) under the <Metadata> <type> elements, the name attribute has the correct namespace.

<propertyname="Description"type="string">This WebPart lists the members of a site</property>

12

</properties>

13

</data>

14

</webPart>

15

</webParts>

Another change you have to do and this one is a tricky one is on the Visual Studio 2010 SharePointProjectItem.spdata file. This is a file I believe Visual Studio uses internally to package and deploy the solution. But the catch is that it doesn’t show by default, so you have to click on the “Show All Files” button in the Solution Explorer and this file will show inside your WebPart folder (see below). Edit the file and change the Namespace attributes according to your new namespace.

Also, don’t forget in that if you change the namespace, in your project properties, make sure it’s reflected in the Default Namespace field in the Application tab of your Project properties (right-click your project name and select properties).

If you want to block search engines from indexing your site you need to create a robots.txt file and place it in the root of your root site.

What is a Robots.txt

Robots.txt is a text (not html) file placed in the root of your site to tell search robots which pages should and should not be visited/indexed. It is not mandatory for search engines to adhere to the instructions found in the robots.txt but generally search engines obey what they are asked not to do.

It is important to note that a robots.txt does not completely prevent search engines from crawling your site (i.e. it is not a firewall) and the fact that you may have a robots.txt file on your site is something like putting a note “Please, do not enter” on your unlocked front door. Put simply, it will not prevent thieves from coming in but the good guys will not open to door and enter.

It goes without saying therefore, if you have sensitive data, you cannot rely 100% on a robots.txt to protect it from being indexed and displayed in search results.

The location of robots.txt is very important. It must be in the main directory because otherwise user agents (search engines) will not be able to find it. They do not search the whole site for a file named robots.txt. Instead, they look first in the main directory (i.e. http://www.sitename.com/robots.txt) and if they don’t find it there, they simply assume that this site does not have a robots.txt file and therefore they index everything they find along the way. So, if you don’t put robots.txt in the right place, don’t be surprised that search engines index your whole site.

Creating a Robots.txt

Launch Notepad

Put the following in your robots.txt file:

User-agent: *
Disallow: /

Save the file as: robots.txt

Adding a robots.txt file to the root of your public anonymous SharePoint site.

Open up your root site in SharePoint Designer.

Double Click the folder All Files

Drag and drop the newly created robots.txt to the All Files folder.

Exit SharePoint Designer.

Alternatively you can create the robots.txt from within SharePoint Designer itself.

To ensure the file is accessible to search engines go to your site URL adding “/robots.txt” at the end.

In SharePoint 2010, Microsoft has taken the Visio Services to the next level by allowing rendering of Visio diagrams and charts within the browser. Users can now use the out of the box Visio web parts to render the Visio diagrams and bring in the seamless integration of business intelligence between Visio, SharePoint and back end data.

SharePoint 2010 provides 3 new client-side object models: Managed, Silverlight and JavaScript. It provides libraries for each and they are located in the below locations.

Managed Object Model

Microsoft.SharePoint.Client.dll

Microsoft.SharePoint.ClientRuntime.dll

ISAPI folder

Silverlight client object model

Microsoft.SharePoint.Client.Silverlight.dll

Microsoft.SharePoint.Client.Silverlight.Runtime.dll

LAYOUTS\ClientBin folder

JavaScript client object model

SP.js

LAYOUTS folder

Each client object model interacts with SharePoint through a Windows Communication Foundation (WCF)

service named Client.svc, which is located in the ISAPI directory. Every request sent as a single Extensible Markup Language (XML) request to the Client.svc service. The results of the server-side calls are then sent back to the calling client in the form of a JavaScript Object Notation (JSON) object.