Mark Arend : Web Parts

Debugging web parts and other SharePoint custom code

markarend — Tue, 09 Sep 2008 15:34:00 GMT

Here are some tips for debugging your SharePoint web parts and other custom code.

1. How do you debug assemblies that are in the GAC?

2. Is there an easy way of attaching the debugger to the right process?

Debugging assemblies that live in the GAC

When debugging an assembly that lives in the GAC, you have to copy the symbol file (.pdb) from your project to the GAC. The problem is, when you open a Windows file explorer to the GAC directory, C:\Windows\assembly, it doesn't behave like a folder that you can drag-and-drop into. You must copy using another method.

To view the GAC as typical folder structure using file explorer, enter %systemroot%\assembly\gac_msil in the Run... dialog box under the start menu. This folder opens the part of the GAC that contains managed code assemblies (from this location in file explorer, you can click the folder-up button to see other parts of the GAC).

From %systemroot%\assembly\gac_msil, locate the folder having the name of your assembly, and open that. Open the folder in there having the correct version number. Finally you’ll see the dll. To debug, drag the .pdb file from your bin\debug directory into that folder. You can also use an xcopy command to do this, now that you see the full path to the dll location. This path will change if you modify your assembly's version number. Note that whenever you upgrade your solution, the .pdb file is removed from that folder, so you have to copy it there again to debug again.

Of course you want to make sure to build in debug mode. Some projects are set up with dependencies on the \release\ directory, which I think is a bad idea, but it's a fact of life sometimes. If you don't want to change your build to Debug, you can quickly change your Release build to emit debug symbols: open the properties page for the project—make sure Configuration is Active (Release)—and on the Build tab, check “Define DEBUG constant” and uncheck “Optimize code” (you may also have to click the Advanced button and select "full" symbols). Now building in release mode will include debug symbols. Be sure to change these settings back once you’re done.

Attaching the debugger to the right process

A number of people have asked me about the "Attach Debugger" menu item they see me use. This is a community feature that's been around for more than a year, but it's good to refresh people's memory of this extremely useful tool.

A SharePoint product team blog entry discusses the Attach Debugger feature that you can install for SharePoint pages. It has a link to the CodePlex project SharePoint 2007 Features that you can install to enable this feature on the Site Actions menu of your sites:

Extremely helpful! And as a bonus, it seems faster than doing it from Visual Studio's Attach Debugger command.

I recommend you look at the SharePoint 2007 Features project, it's got lots of goodies besides this.

Technorati Tags: SharePoint Development

Colleagues, Social Distance & Relevance in People Search; Social Networking tools

markarend — Thu, 01 May 2008 16:16:00 GMT

MOSS provides some very powerful features to enable the new buzzword "social networking." Discussions about these can be found pretty easily, and I give an overview of some tools near the end of this posting. But specifics about how some of the details work has been devilishly hard to find... until now. Through discussions with various people in-the-know, I've been able to assemble answers to common questions around People Search and MySite web parts.

Social Distance

By default, the results on the People Search page are ordered by Social Distance. What the heck is that? It's an ordering of results based on colleague relationships. Here's how it's computed:

Search results are always returned to the search results page sorted by relevance.
When viewing results by social distance, additional processing on the search results page is used to group the results:
- The first 3 pages of search results are grouped by colleague-ness: first your colleagues appear, then colleagues of your colleagues, then everyone else.
- Within each group, the ordering is still by relevance.
- When paging through results, another 3 pages of results will be grouped once you reach page 4, then page 7, etc.

By default, 10 results appear per page, so this groups people in batches of 30. If you customized the People Search results page to show 25 results per page, this would group people in batches of 75.

There are potentially some quirks with this algorithm that was designed to give the best value in a lightweight manner. Your colleagues will appear at the top of the list on page 1, but if you have lots of colleagues, more of them might appear on page 4. This is because the colleague grouping takes place on the client, starting with a relevance ranking. So if some of your colleagues are relevance-ranked after 3 pages worth of results, these will be grouped once you get to the next set of 3 pages (page 4, page 7, etc). Based on relevance, these people should be less relevant to your query.

The People Search results page allows you to toggle the results ordering to only Relevance, ignoring the Social Distance grouping.

Relevance

Relevance ranking in people search is the same as that used in regular search across lists and documents. I'm told that the ranking algorithm MOSS uses in all cases is BM25F.

Conceptually, a user's profile is treated as a document about that person with their name as the title. At a basic level, the more search query terms that appear in the person's profile, the more relevant the result. Matches against a few special fields (e.g. name, alias) are returned in the high confidence webpart.

Note that the names of discussion lists that a user belongs to are included in that user's profile information. This means that a people search for "rock climbers" should return all of the people who are members of a distribution list named "Rock Climbers at Contoso" as well as anyone who has the phrase "rock climbers" in their profile information, such as in their "About Me" field.

Colleagues

Here's where the real value of social distance and other meaningful relationships is computed.

A list of your colleagues is stored in the profile database. During a profile import, this list is initially populated with a set of "immediate colleagues" that are computed from your profile properties: manager, peers and direct reports. This way, when you first look at your Colleagues web part, it's not blank.

Then, from an editing page on your Profile, you can edit your colleagues list to add & remove specific people, and to group them and set their visibility to other people. Also from here, you can ask SharePoint to suggest other colleagues, and these suggestions are collected from several places.

My Microsoft badge photo, 1999!

From your MySite page (or your Profile page, which is available even if MySites are turned off), click Colleagues to edit your colleague list.

Where do colleagues come from?

Immediate colleagues
...automatic: during profile import; comprised of:
- Your manager
- Your peers (others who report to your manager)
- Your direct reports
Colleagues added by you
...manual: via editing page on your Profile
Suggested colleagues
...lookup: manually guided via editing page on your Profile; comprised of:
- Sent items in Outlook. Periodically (every 5 days or so, depending on usage) Outlook analyzes Sent Items for common recipients, weighted by frequency of contacts and other factors. This is how Outlook is able to suggest likely recipients when you begin typing their name in the To: line, and in my experience, it seems to work pretty well. When you click Suggested colleagues, it collects these names from Outlook via an ActiveX control, and adds them to the list of suggestions.
- Office Communicator contacts are examined; that is, those contacts that you've added to your Office Communicator client from the company directory. These are also collected from the Communicator client via an ActiveX control.
- Site Memberships are all sites in which you are explicitly included in the "~Members" group for the site (where ~ is your site name). Other users who are also explicitly included in the ~Members group on those sites are suggested as your colleagues. This information is collected by a WSS profile synchronization timer job.
- DG (Distribution Group) Memberships are examined for suggestions. Distribution groups stored in AD are collected during the AD import.

Colleagues from these sources are collected and the top 20 or so are displayed as suggestions when you click "Add Colleague" on your colleague editing page. It's not fruitful to pursue a more detailed understanding of this calculation, because the recommendation for improving the "quality" of colleagues found is the same: people associated with items you access more often are more likely to be suggested as your colleagues. If you don't like the suggestions, you can remove individuals from the suggestion list one by one or all at once from this page, then get a new list of suggestions.

Privacy

Whoa! Is SharePoint looking at my email? I don't want that, how do I prevent it?

First, SharePoint's not looking at your emails. It gets information about who you sent emails to by asking Outlook for that information. Second, it will never do this without asking your permission. You can always say no:

If you say Yes, then SharePoint will assemble a list of suggested colleagues for you, and you can accept or reject these suggestions. But even if you say No, you can still edit your colleagues to search for and add new people, and to set the privacy of who should see that they are your colleague (Everyone, My Colleagues, My Workgroup, My Manager and Only Me):

Social Networking tools

Why did we go through all this trouble to try and figure out who your colleagues are? Social Networking, baby! We spent a good bit of time on the inputs and the outputs of this to make it a really useful function, instead of just paying lip service to it.

The inputs are the information about who your colleagues really are. A simple option would have been to just provide a place for you to register your colleagues, and not go through all this supposedly intelligent guesswork. But that would have made it almost useless, because most people are just not going to take the time to populate this list, and even fewer will maintain it as their colleagues change over time, which is natural.

SharePoint uses the information already embedded in your company's infrastructure and the changing data you deal with on a daily basis to help you connect with the right people.

Sounds like market-speak, but that's really the goal and I think it does an amazing job.

The outputs are the tools that SharePoint can provide based on this colleague information. Consider some of these details:

People Search ranking by Social Distance. By default, the top people returned when you search for a name will be the people you most likely want to find: people you've communicated with recently, perhaps as a participant on an email thread or a collaborator on a site, and now you want to find more information about them.
In Common with You web part on My Profile page. When you view someone else's profile (for example, by clicking their People Search result), this web part shows you a list of people that you both may have in common. This is useful to quickly understand business relationships that you may need to know about. Categories shown are
- Manager we both report under
- Colleagues we both know
- Memberships we both share
Colleague Tracker web part on MySite. This shows you recent changes to user properties of your colleagues, effectively a newsletter of what's new with people you work with. Information you can track includes
- Anniversaries
- Profile property changes
- Membership changes
- New documents this person has posted
- Out of Office status
- Blog postings from this person
Colleagues web part on My Profile page. This displays your current list of colleagues, grouped into categories that you may have applied.
Memberships web part on MySite. This shows Distribution Lists and SharePoint Sites of which you are an explicit member. For SharePoint Sites, it is rather specific: you must appear as an individual member of the ~Members group on the site (where ~ is the site name). If you have access to the site through a different configuration, such as being a member of the ~Owners group, or being a member of an Active Directory Security Group that is a member of the ~Members group, this is not counted. Otherwise, everyone would very likely see all the portal sites displayed as their memberships, and that would not be useful.
Organization Hierarchy web part on My Profile page. This shows your manager, your peers (others who report to your manager) and your direct reports, if you have any.

These are some of the tools that MOSS provides for Social Networking; I've highlighted the ones that use profile data and the powerful "colleague" pattern to show meaningful relationships among people. For a better introduction to the full set, see the product team's Enabling and Managing Social Networks for Business use with MOSS.

Technorati Tags: SharePoint,Social Networking,MySites,People Search,Social Distance

Web part comparison: SPS 2003 & WSS v2 --> MOSS 2007 & WSS v3

markarend — Fri, 08 Dec 2006 20:01:00 GMT

Web parts shown in Gray were available in previous version, but not in current version.

Web parts shown in Green are available in previous version and current version

All other web parts are new to the current version.

I threw this list together fairly quickly, please let me know if you find any errors.

Web Part Name	File Name	SPS 2003	WSS v2	MOSS 2007	WSS v3
Advanced Search Box	AdvancedSearchBox.dwp			Yes
Authored List Filter	AuthoredListFilter.dwp			Yes
Topic Assistant Suggestions	Autocat.dwp	Yes
	BusinessDataActionsWebPart.dwp			Yes
	BusinessDataAssociationWebPart.webpart			Yes
	BusinessDataDetailsWebPart.webpart			Yes
	BusinessDataFilter.dwp			Yes
	BusinessDataItemBuilder.dwp			Yes
	BusinessDataListWebPart.webpart			Yes
Area Details	Catdetail.dwp	Yes
Sites in Category (SiteDirectory)	CategoryResultsWebPart.webpart			Yes
Categories (SiteDirectory)	CategoryWebPart.webpart			Yes
Colleague Tracker	contactlinks.dwp			Yes
Contact Details	contactwp.dwp			Yes
Content By Query	ContentQuery.webpart			Yes
Date Filter	DateFilter.dwp			Yes
Filter Actions	FilterActions.dwp			Yes
Group Listings	GroupedListings.dwp	Yes
KPI Details	IndicatorWebPart.dwp			Yes
Views from SAP	IViewWebPart.dwp			Yes
Key Performance Indicators	KpiLisWebPart.dwp			Yes
News	LatestNews.dwp	Yes
Links for You	LinksForYou.dwp	Yes
Memberships (in other sites)	memberships.dwp			Yes
Excel Web Access	Microsoft.Office.Excel.WebUI.dwp			Yes
Content Editor	MSContentEditor.dwp	Yes	Yes	Yes	Yes
Image Web Part	MSImage.dwp	Yes	Yes	Yes	Yes
Members	MSMembers.dwp		Yes	Yes	Yes
Page Viewer	MSPageViewer.dwp	Yes	Yes	Yes	Yes
Form Web Part	MSSimpleForm.dwp	Yes	Yes	Yes	Yes
Relevant Documents	MSUserDocs.dwp			Yes	Yes
User Tasks	MSUserTasks.dwp			Yes	Yes
XML Web Part	MSXml.dwp	Yes	Yes	Yes	Yes
Your Recent Documents	Mydocs.dwp	Yes		Yes
My Workspace Sites	Myworks.dwp	Yes		Yes
News Areas	NewsAreas.dwp	Yes
News for You	NewsForYou.dwp	Yes
SQL Server Analysis Services filter	OlapFilter.dwp			Yes
My Mail Folder	Owa.dwp	Yes		Yes
My Calendar	Owacalendar.dwp	Yes		Yes
My Inbox	Owainbox.dwp	Yes		Yes
My Tasks	Owatasks.dwp	Yes		Yes
Page Field filter	PageContextFilter.dwp			Yes
People Search Box	PeopleSearchBox.dwp			Yes
People Search Core Results	PeopleSearchCoreResults.webpart			Yes
Query String (URL) filter	QueryStringFilter.dwp			Yes
My Links	Quicklinks.dwp	Yes		Yes
RSS Viewer	RssViewer.webpart			Yes
	SearchActionLinks.webpart			Yes
	SearchBestBets.webpart			Yes
	SearchBox.dwp			Yes
	SearchCoreResults.webpart			Yes
	SearchHighConfidence.webpart			Yes
	searchpaging.dwp			Yes
	searchstats.dwp			Yes
	searchsummary.dwp			Yes
Site Aggregator	siteFramer.dwp			Yes
SharePoint List filter	SpListFilter.dwp			Yes
My Alerts Summary	Subscrip.dwp	Yes
Summary Links	SummaryLink.webpart			Yes
Navigation Hierarchy	TableOfContents.webpart			Yes
I need to...	TasksAndTools.webpart			Yes
Text Filter	TextFilter.dwp			Yes
This Week In Pictures	ThisWeekInPictures.dwp			Yes
Top Sites	TopSitesWebPart.webpart			Yes
Area Contents	Toc.dwp	Yes
Current User filter	UserContextFilter.dwp			Yes
WSRP Consumer	WSRPConsumerWebPart. .dwp			Yes
List views
Announcements		Yes	Yes	Yes	Yes
Contacts		Yes	Yes	Yes	Yes
Events		Yes	Yes	Yes	Yes
General Discussions		Yes	Yes	Yes	Yes
Links		Yes	Yes	Yes	Yes
Shared Documents		Yes	Yes	Yes	Yes
Tasks		Yes	Yes	Yes	Yes
Document Library		Yes	Yes	Yes	Yes
Image Library		Yes	Yes	Yes	Yes

RSS Viewer web part and authenticated feeds

markarend — Tue, 03 Oct 2006 18:46:00 GMT

RSS Viewer web part authentication requirements

In B2, configuring the RSS Viewer web part to display an RSS feed from a MOSS site nearly always worked without difficulty. In B2TR, you may encounter a stubborn error “The RSS webpart does not support authenticated feeds” when trying to display an RSS feed from a MOSS site. The authentication behavior has changed, to match the original design that was not implemented properly in B2. RSS Viewer will now only work with Authenticated feeds (default for MOSS) when the MOSS server is setup with Kerberos authentication. Technical details: In B2, the machine account was used to access the feed; since this account is part of “All Authenticated Users” most feeds just worked. However, use of the machine account was considered to pose a security vulnerability. In B2TR, this was fixed to connect to feeds as anonymous, then delegation support was explicitly added by having ASP.Net negotiate the authentication mechanism.

Changing to Kerberos authentication

1. On the Central Administration page, click Application Management.

2. Under the Application Security section, click Authentication Providers.

3. Click the Default provider, and change Integrated Widows authentication to Negotiate (Kerberos)

If SharePoint and the databases it uses are hosted on the same server, this is the only change required to enable RSS Viewer functionality to RSS feeds hosted by SharePoint.

If the SharePoint databases are hosted by a different server than is hosting SharePoint, further configuration is required to enable Kerberos delegation. This is the recommended scenario for farm deployments. To enable Kerberos delegation for a SharePoint web application, the account used for its application pool identity must be configured as “trusted for delegation” and have an SPN registered (see below). If using Network Services for the AppPool identity, then this applies to the machine account. Otherwise, it applies to the domain account configured for the AppPool identity. The machine account of the database server must also have an SPN registered, although it is not necessary for it to be trusted for delegation. The end-user accounts require neither an SPN nor “trusted for delegation.”

In an AD environment whose Domain Functional Level is set to Windows Server 2003, this level of trust can be focused using Constrained Delegation. This ensures that the delegation trust is only permitted between the SharePoint WFE servers and the correct database server.

SPN

The MSDN article Security Briefs: Credentials and Delegation discusses several topics regarding SPNs and Kerberos delegation that are appropriate for this scenario, including use of the SETSPN and KERBTRAY tools, the "trusted for delegation" attribute, and how to configure Kerberos constrained delegation.