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” 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.
MOSS has many default timer jobs; information about them can be useful to understand the workings of your MOSS farm, and potentially to troubleshoot problems or plan for related types of customizations.
The attached document provides a list of all MOSS timer jobs provided out-of-box, with some additional notes about them.
Sometimes you just need a list of things provided by MOSS, in order to plan what kind of things you will make available to users within your architecture.
The attached document lists all out-of-box Lists, Web Parts, Site Templates and Site Actions provided out-of-box by MOSS, along with their descriptions and availability.
The site usage reports that MOSS provides are fairly simple, but can be useful if you haven't got any other tools for tracking site usage. One problem with them, however, is that the information they present is not really explained anywhere. Columns are often named "Value" and sometimes it's not clear exactly what the value represents. Another example is what does "Requests" actually measure? The answer is that Requests always measures Page Views, not all HTTP requests for individual items like images, style sheets, etc.
The attached document gives clear, detailed explanations of all out-of-box report elements.
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.
I've worked with several companies who have between 100,000 and 200,000 employees. Naturally, they want to architect a solution for MySites that can accommodate everyone in the company. TechNet has information in the Plan for software boundaries article, but a few numbers are ambiguous or conflicting. In this post I'll try to clear some of that up.
The limits I'll respect from this article are:
- 100 GB maximum size for Content Database (DB)
- 50,000 site collections per Content DB
Scale-out
The primary scale-out strategy is to use multiple content databases in the MySite web application. To meet the guideline of 50,000 site collections per DB, you should plan a minimum of 2 content databases to handle 100,000 MySites.
Next, consider Throughput vs. Site Collections discussed in the TechNet article. The most striking visual impact of this graph (reproduced below) is that performance appears to drop off dramatically as the number of site collections per content database grows to 50,000. It looks a bit alarming. But it's important to examine the numbers.
Let's look at some points on the graph. Note this is a sample from testing; your specific numbers may vary, but we'll assume inflection points are in roughly the same places.
- At 10,000 site collections per content database, the number of requests per second (rps) is still above 100.
- From about 14,000 - 16,000 site collections, throughput decreases very rapidly.
- After 16,000 site collections, throughput "bottoms out" near 50 rps and stays pretty much the same through 50,000 site collections.
As a general approach to optimizing throughput for any arbitrary scenario, we might say that limiting content databases to 10,000 site collections is a good rule of thumb, because adding 50% more databases at this point cuts throughput in half. But you should think through anticipated usage patterns for the particular web application and site collections.
MySites have a common usage pattern: these site collections tend to have relatively small quotas, and don't get a lot of concurrent traffic. A relatively small percentage of MySites are used heavily; these tend to be people who enjoy publishing material or experimenting with information techniques. In many situations, 50 rps will be sufficient for MySite traffic. This means we're free to set the limit of site collections per content database on the MySite host at any value up to the recommended limit of 50,000.
The next limiting factor is the overall size of the content database: 100 GB is recommended as the maximum. This, plus the desired MySite storage quota, will let us compute the optimum number of databases.
| Individual MySite quota (MB) | 2 | 5 | 10 | 20 | 25 |
| Number of MySites per 100 GB content DB | 51,200 | 20,480 | 10,240 | 5,120 | 4,096 |
| # content DBs per 100,000 users | 2 | 5 | 10 | 20 | 25 |
Cool Rule: Assuming 100GB as the maximum size of a content database, the number of databases you should plan for—per 100,000 users—is equal to the quota of each site collection in MB!
Other combinations of maximum content DB size or number of users will not line up this way. To compute the number of content databases, the following formulas may be used.
- # site collections per DB = (Max size of DB in GB * 1024) / (MySite quota in MB)
- # content DBs = (Number of MySites) / (# site collections per DB)
For the second formula, you must always round fractions up to the next whole number (use the ceiling function in Excel).
Scale-up
To further ensure the overall performance of SharePoint when using multiple content databases, configure SQL Server so that the databases are hosted on different physical drives (spindles). This is usually possible with SAN storage solutions also. My instinct is that you'd want to balance this with the scale-out strategies and usage patterns. If you had 200,000 users with MySites and a large portion really began to use MySites heavily, then you might want to use 20 content databases distributed across 5 or 10 physical drives.
Next, note that MySites usually cause significantly more transactions in the User Profile database than collaboration or publishing sites, because more web parts that present and manipulate profile information are available on MySites. As you grow the number of MySites, the CPU, memory, storage and IOPS available for your User Profile DB becomes more important. Therefore you want to consider putting this database on a separate physical drive also. For very large user populations and/or heavy anticipated use of MySites, you could even consider using a separate instance of SQL Server for the Profile DB.
The whitepaper SharePoint database performance recommendations gives specific recommendations for increasing performance via the database.
What about TechNet’s limit of 150,000 site collections per web app? Well, as of this writing, the article shows two different numbers for the same limit (the other is 50,000)... clearly, there is still some ambiguity over this. Recent anecdotal evidence hints that 200,000 site collections can be hosted on one web application and still perform well. If I find more details about this I'll post another entry.
Areas a performance hit might be seen due to larger numbers are those that enumerate site collections in a web app. There are pages in Central Administration (CA) that do this, and it can be mitigated by using the "find" function in the CA page or by using stsadm commands to perform some functions such as MySite deletion.
If you want to plan for growth toward heavy MySite usage, you may want to consider using more than one web application to host them. It's possible to configure multiple web applications to host MySites. When doing this, audiences can be defined to map users to MySite web apps. A very common approach is to use geography as the audience, especially when a company has datacenters around the world that service users in their part of the world. This has the added benefit of hosting a user's MySite from a datacenter nearer to them. Refer to TechNet article Manage My Site host locations for much more detailed information on enabling this scenario.
However, this may not be as balanced an approach for a domestic as it is for global companies. The ideal arrangement is to find a natural organization of people that splits the whole population into just a few categories of reasonably equal quantities, and is reflected in user profile data. Such a perfect arrangement may not exist; review your user profile database to look for natural categories that can uniquely classify everyone.
When someone creates a MySite, they are automatically given full control of that site. More accurately: a MySite is a site collection; the creator becomes the first & only Site Collection Administrator; the creator is made a member of the Owners group.
Some people feel that this is too much control, and they'd like to limit it in some way. I found a way to meet this relatively simple request, but the answer is most certainly not simple.
Basically, you have to follow Steve Peschka’s approach described in the blog entry customizing My Sites as the framework for doing this. Then, add code to that scheme that knows how to change the security. There are a few added challenges:
- You must do two things: 1) change the creator’s group membership and 2) remove them as a Site Collection Administrator.
- To give the creator of the MySite specific privileges, you typically want to create a custom privilege level and add the user into that group. The benefit is that you can tweak this to allow/prevent actions at a fairly granular level, such as being able to block the ability to add subsites.
- The creator of the MySite is the only Site Collection Administrator, so you can’t remove this person from this role until you first put someone else in there. For best governance, this should be a user account that’s not really associated with an individual, but shared among trusted admins. Unfortunately it must be a user account, not a group.
- There seems to be a timer job that fixes up the title of the MySite to match the name of the site administrator… so you need some code that resets this back every time the user opens the site.
Why can’t we just change the MySite site definition (template)? Two reasons:
- Modifying the MySite site definition is “unsupported” by Microsoft. If you did it, then wanted help with problems related to it, the support engineer would make a best effort, but could not guarantee a fix. Steve’s article talks more about this.
- Moot point! User security is not stored in the site definition, so even if it were supported to modify it, there would be nothing to do.
Below are code samples that address the challenges listed above. Your job would be to integrate them with Steve Peschka’s code. Sorry I can’t give a more complete solution. This is one task that is very difficult to accomplish in SharePoint, and the methods described are the only way we know of doing it in a supported way.
(BTW, I use lots of try...catch blocks here to get the most granular logging. You can implement Utility.LogMessage any way you like; I use MSDN's Trace Log Example to write to the ULS logs, and CodePlex's Log Viewer Feature to read them.)
public void RestrictMySiteOwner()
{
SPUserInfo originalOwnerInfo = new SPUserInfo();
SPUserInfo newOwnerInfo = new SPUserInfo();
// Store the original owner in site properties so we can restore it later if necessary
try
{
StoreValueInSiteProperty(_curWeb, "OriginalOwner", MakeUserInfoString(originalOwnerInfo));
Utility.LogMessage("Stored original administrator in site property.");
}
catch (Exception ex)
{
Utility.LogMessage("Error: can't store original administrator in site property. " + ex.Message);
}
// Switch out the primary site administrator with a pre-defined one.
try
{
newOwnerInfo.LoginName = "DOMAIN\MySitesAdmin";
newOwnerInfo.Email = "mysitesadmin@customer.com";
newOwnerInfo.Name = "MySites domain manager";
newOwnerInfo.Notes = "Owner of all MySites";
originalOwnerInfo = ReplacePrimarySiteAdministrator(_curWeb, newOwnerInfo);
Utility.LogMessage("Switched primary administrator.");
}
catch (Exception ex)
{
Utility.LogMessage("Error: can't replace primary administrator. " + ex.Message);
}
// Add the My Site creator to a group with limited permissions to control what is permissible on the site
try
{
ChangeCurrentUserPermission(_curWeb, "Restricted Owner");
Utility.LogMessage("Changed current user permissions.");
}
catch (Exception ex)
{
Utility.LogMessage("Error: can't change current user permissions. " + ex.Message);
}
// Reset the name of the site back to original owner (was changed by switching primary site admin)
try
{
SetSiteTitle(_curWeb, originalOwnerInfo.Name);
Utility.LogMessage("Reset site title.");
}
catch (Exception ex)
{
Utility.LogMessage("Error: can't reset site title. " + ex.Message);
}
}
protected SPUserInfo ReplacePrimarySiteAdministrator(SPWeb site, SPUserInfo newAdminInfo)
{
SPUser originalOwner = null;
SPUserInfo originalOwnerInfo = new SPUserInfo();
SPSecurity.RunWithElevatedPrivileges(delegate()
{
// Get the parent site collection
SPSite sitecollection = site.Site;
originalOwner = sitecollection.Owner;
originalOwnerInfo = Utility.GetUserInfo(originalOwner);
if (newAdminInfo.LoginName != originalOwnerInfo.LoginName)
{
try
{
// Add new admin to Full Control group
SPRoleDefinition admins = site.RoleDefinitions["Full Control"];
if (admins != null)
{
SPRoleAssignment roleAssignment =
new SPRoleAssignment(newAdminInfo.LoginName, newAdminInfo.Email,
newAdminInfo.Name, newAdminInfo.Notes);
SPRoleDefinitionBindingCollection roleDefBindings =
roleAssignment.RoleDefinitionBindings;
roleDefBindings.Add(admins);
site.RoleAssignments.Add(roleAssignment);
//site.Update(); // Don't need to do this
}
// Reset owner of site collection to new admin
sitecollection.Owner = site.Users[newAdminInfo.LoginName];
sitecollection.Owner.Update();
}
catch (SPException ex)
{
// We may get here if the user running this thread is the same as the
// aministrator we're trying to remove.
Utility.LogMessage("Error: can't replace primary administrator. " + ex.Message);
}
}
});
return originalOwnerInfo;
}
protected void ChangeCurrentUserPermission(SPWeb site, string roleDefinitionName)
{
SPUser curUser = site.CurrentUser;
string curUserName = curUser.LoginName;
SPRoleDefinition roleDefFull = null; // Full control privilege level
SPRoleDefinition roleDefContributor = null; // Contributor privilege level
SPRoleDefinition roleDefLimitedOwner = null; // Our new privilege level
// Create new role definition
try
{
// Get existing role definitions
roleDefFull = site.RoleDefinitions["Full Control"];
roleDefContributor = site.RoleDefinitions["Contribute"];
// Create custom role definition
roleDefLimitedOwner = new SPRoleDefinition();
roleDefLimitedOwner.Name = roleDefinitionName;
roleDefLimitedOwner.Description = "Permission settings for the owner of this MySite.";
site.FirstUniqueRoleDefinitionWeb.RoleDefinitions.Add(roleDefLimitedOwner);
site.FirstUniqueRoleDefinitionWeb.Update();
// Get the new role definition again... makes sure the Update took all the way or something.
roleDefLimitedOwner = site.FirstUniqueRoleDefinitionWeb.RoleDefinitions[roleDefinitionName];
// Set permissions of new role... start from Contributor as base.
roleDefLimitedOwner.BasePermissions = roleDefContributor.BasePermissions;
// To ADD a permission, use Bitwise-Or assignment: permissions |= permission
// To REMOVE, use Bitwise-And assignment to Complement: permissions &= ~permission
roleDefLimitedOwner.BasePermissions |= SPBasePermissions.CancelCheckout;
roleDefLimitedOwner.BasePermissions &= ~SPBasePermissions.AddDelPrivateWebParts;
roleDefLimitedOwner.BasePermissions &= ~SPBasePermissions.UpdatePersonalWebParts;
roleDefLimitedOwner.Update();
}
catch (Exception ex)
{
Utility.LogMessage("Error: can't create new permission group \""
+ roleDefinitionName + "\". " + ex.Message);
}
// Add owner to new role definition
try
{
SPRoleAssignment assignment = new SPRoleAssignment(curUser);
if (roleDefLimitedOwner != null)
{
assignment.RoleDefinitionBindings.Add(roleDefLimitedOwner);
}
else
{
//Workaround: for now we just make owner a contributor
assignment.RoleDefinitionBindings.Add(roleDefContributor);
}
site.RoleAssignments.Add(assignment);
//site.Update(); // Don't need to do this
}
catch (Exception ex)
{
Utility.LogMessage("Error: can't add user \"" + curUserName
+ "\" to new permission group \"" + roleDefinitionName + "\". " + ex.Message);
}
// Remove owner from Full Control
try
{
SPRoleAssignment userRoleAssignment = UserRoleAssignment(site, curUser, roleDefFull);
if (userRoleAssignment != null)
{
userRoleAssignment.RoleDefinitionBindings.Remove(roleDefFull);
userRoleAssignment.Update();
}
//site.Update(); // Don't need to do this
}
catch (Exception ex)
{
Utility.LogMessage("Error: can't remove user \"" + curUserName
+ "\" from default permission groups. " + ex.Message);
}
}
private SPRoleAssignment UserRoleAssignment(SPWeb site, SPUser curUser, SPRoleDefinition curRoleDef)
{
foreach (SPRoleAssignment roleAssignment in site.RoleAssignments)
{
if (roleAssignment.Member.ID == curUser.ID)
{
foreach (SPRoleDefinition roleDefinition in roleAssignment.RoleDefinitionBindings)
{
if (roleDefinition.Id == curRoleDef.Id)
{
return roleAssignment;
}
}
}
}
return null;
}
protected void StoreValueInSiteProperty(SPWeb site, string propertyName, string propertyValue)
{
if (site.Properties.ContainsKey(propertyName))
site.Properties[propertyName] = propertyValue;
else
site.Properties.Add(propertyName, propertyValue);
site.Properties.Update();
}
protected void SetSiteTitle(SPWeb site, string title)
{
try
{
site.Title = title;
//site.Update(); // Don't need to do this
}
catch (Exception ex)
{
Utility.LogMessage("Error: can't set site title to \"" + title + "\". " + ex.Message);
}
}
This is a topic near and dear to my heart. I've spent many hours helping customers plan and execute a wide range of customizations for MOSS 2007.
Now, the ECM Team (Enterprise Content Management) has published an exhaustive paper on these topics. At least, I was exhausted reading it! No, really, it's a great guide and covers so many areas that normally don't even get touched on.
Download: http://go.microsoft.com/fwlink/?LinkId=110087.
Announcement and request for feedback:
http://blogs.msdn.com/ecm/archive/2008/03/11/announcing-design-and-build-sites-for-office-sharepoint-server-2007.aspx.
Topics
- Customization approaches (Basic, Intermediate, Advanced - Author centric, Advanced - Developer centric)
- Site Elements (Authored elements, Developed elements)
- Environments (Dev, Config mgt, Integration, Authoring, Pilot, Production)
- Tools & Processes
- Development team roles (Architect, Developer, Designer, Author, Tester, Admin)
- Customization Scenarios (Corporate extranet, Enterprise internet)
- Upgrading from SPS 2003 to MOSS 2007 (addressing customizations)
- Upgrading from CMS 2002 to MOSS 2007 (pointers to resources)
- Deployment (Authored, Developed)
- Solution packages
- Roadmaps (Sites & Subsites, Page design, Document mgt, InfoPath, Workflows, BI, Records mgt)
This is a tremendously valuable resource, go get it!
When developing web parts and other components with code, it's important to remember that operations performed by code may require certain privileges. During development, the code runs in the security context of the developer, who is usually a server administrator. This means all operations are permitted, so access problems don't arise. During testing and production, however, the security context of the code may be different because it's being invoked by testers and end-users.
Therefore, all components should be tested with several end-user accounts: one would be the developer’s account which is usually a server admin; that’s how most people do their unit testing. But tests should also be made with an account of minimal privilege, say Visitor. Some components might be doing things with the object model that will only work when an administrator invokes it. If this turns out to be the case, a technique called “elevation of privilege” can be used to overcome it. See MSDN article Running Commands with Elevated Privileges in Windows SharePoint Services 3.0 for an explanation of doing this.
What code needs to be tested using different privileges?
1. Code that's invoked as the result of an end-user action. An example is a custom web part that is displayed on a page. The end-user opens the page and this is what invokes the web part code under the user's security context. A counter-example is timer job code that is invoked by SharePoint.
2. Code that uses the SharePoint API. This is typically where security errors arise. If a component does not use the SharePoint API, then chances are it will not need to elevate its privilege. To be entirely sure, it should be tested at minimum privilege, but this criterion can be used to prioritize testing of other components higher.
How can a developer test with different accounts?
The simplest approach is to create three accounts "Test Visitor," "Test Member," and "Test Owner" in Active Directory and then to add these accounts to matching groups on the test sites.
First, the developer must decide in what security contexts the component is supposed to work. For example, most end-user web parts should work for users signed on as Test Visitor. On the other hand, an stsadm extension is only invoked by a server admin and should not be tested with a minimum privilege account.
"Sign on as different user" can be used to choose one of the test accounts as appropriate; however, in some cases, this approach does not seem to “stick” based on browser state or browsing behavior (e.g. browsing to My Site when browser is configured for automatic logon). The best way to ensure that the desired account is used is to configure the browser to always prompt for credentials, then to open a new browser window to begin testing. Then, re-run all unit tests that exercise the component directly (not, say, the deployment of the component).
Wait.. A posting not about SharePoint? How can this be? Well, it's somewhat related to SharePoint, since so many people use Virtual PC to host a development SharePoint environment. Since SharePoint requires Windows Server 2003, that's the best choice for us laptop users. Anyway, this is just a quick comparison between some points of these two products.
|
Feature |
VPC |
Virtual Server |
|
Shared Folders? |
Yes |
No |
|
Copy-n-paste? |
Yes |
No |
|
Drag-n-drop? |
Yes |
No |
|
Map a virtual NIC to a wireless physical connection? |
Yes |
No |
|
Compact disk image to a separate location? |
Yes |
No |
|
Management tools for multiple guest OS? |
No |
Yes |
|
Performance |
Great* |
Great*+1 |
|
Runs as Windows Service
(can auto-restart after host restart) |
No |
Yes |
*Performance really can be very good, on two conditions: enough physical RAM on your host (2GB will do, but 4GB is much better), and putting the virtual hard drive on a physical drive other than the one holding the host OS. On a laptop, a USB 2.0 external drive works very well. Be sure to "safely remove..." the USB drive before unplugging it.
Bottom line: if your host is a laptop or desktop, use VPC. If your host is a server in the datacenter, use Virtual Server.
Sometimes people ask me about VMWare's products. Well, I don't run them so I can't say, but Andrew Connell has a good blog posting examining some of the differences, especially related to how we use them as SharePoint developers, consultants and trainers.
Do you sometimes use a "reflector" program to examine SharePoint source code? This can be necessary to:
- Understand out how SharePoint is doing something, to find what elements can be customized.
- Understand what members to override in classes you create that inherit from SharePoint classes.
The de facto standard program for doing this is Lutz Roeder's Reflector. The MSDN article on ten must-have tools has a great description of how helpful it can be and how to use it.
One thing the article doesn't tell you is where to find SharePoint's assemblies; fortunately it's not that hard. Click "Open" in Reflector, then with a little bit of browsing, most people easily find the dlls in the ISAPI directory of the "12-hive" (C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\ISAPI).
Open one or more of these dlls, then browse the classes to see how SharePoint's put together… the Disassemble tool is exceedingly useful! Note: the code you see is reconstructed from MSIL, into the language of your choice (C#, VB, Delphi, C++ or Chrome)… the product teams didn't really use all those goto's!
However, some SharePoint namespaces seem to be missing or incomplete when viewed in Reflector. This had me baffled for quite some time, until I found the following.
Some SharePoint assemblies are stored in the _app_bin directory of the web application instead of the ISAPI directory in the 12-hive. Presumably, the reason for distributing certain code into the web application's root is related to something like stability, security or scalability. But the important point is if you're using Reflector to look at SharePoint code, you may need to look here as well.
This is especially true for a namespace like Microsoft.SharePoint.ApplicationPages. Two assemblies contribute members to this namespace: 12\ISAPI\Microsoft.SharePoint.dll and Inetpub\...\_app_bin\Microsoft.SharePoint.ApplicationPages.dll. If you just reflect the one in ISAPI, you'll see very few members; the ones you typically want to look at are in _app_bin!
SharePoint DLL locations
Here's a list of all the SharePoint assemblies and where they appear.
12\ISAPI
Microsoft.Office.Excel.Server.Udf.dll
Microsoft.Office.Excel.Server.WebServices.dll
Microsoft.Office.Policy.dll
Microsoft.Office.Server.dll
Microsoft.Office.Server.Search.dll
microsoft.office.workflow.tasks.dll
Microsoft.SharePoint.dll
microsoft.sharepoint.portal.dll
Microsoft.SharePoint.Portal.SingleSignon.dll
Microsoft.SharePoint.Portal.SingleSignon.Security.dll
Microsoft.SharePoint.Publishing.dll
Microsoft.SharePoint.Search.dll
Microsoft.SharePoint.Security.dll
microsoft.sharepoint.WorkflowActions.dll
Not .NET assemblies (can't reflect):
OWSSVR.DLL
SHTML.DLL
SSOCLI.DLL
Inetpub\wwwroot\wss\VirtualDirectories\<web app>\_app_bin
Microsoft.Office.DocumentManagement.Pages.dll
Microsoft.Office.officialfileSoap.dll
Microsoft.Office.Policy.Pages.dll
Microsoft.Office.SlideLibrarySoap.dll
Microsoft.Office.Workflow.Pages.dll
Microsoft.Office.WorkflowSoap.dll
Microsoft.SharePoint.ApplicationPages.dll
stssoap.dll
Obfuscation tips
Sometimes, not too often, when Reflector is disassembling source code for you, it will show "This item is obfuscated and can not be translated" instead of code. I think the product team did this for some of the more "sensitive" areas of the code (such as LogInAsAnotherUser) and also on a bit of a random basis, perhaps to prevent fully reverse engineering the product. In any case, by changing the translation language to IL in Reflector, you might get enough information from the MSIL code to answer the question that drove you there in the first place. For example, sometimes I just need to know what modules are being called, or what strings are being used to find other resources in the 12-hive; these are still visible in MSIL.
MySites are very interesting on many levels. When you start to think about how to architect, deploy or customize them, you may encounter some initial confusion and a lack of detailed information. For instance, did you know that your MySite's Home page and the My Profile page are in completely different site collections? What's up with that?
The reason is that a My Profile page is provided for every user in the portal regardless of whether they have a MySite, or even if MySites is disabled. Actually, a single page renders every MyProfile page: http://mysite/person.aspx. This page has code that displays a "Home" tab linking to the user's MySite at http://mysite/personal/userid/default.aspx if it exists. The Home tab makes it appear that these two pages are part of the same site. But the URLs hint at the truth: the My Profile page is on one site collection, while the user's MySite Home page is on another.
You knew each MySite is hosted in its own site collection, right? When a MySite is created for a user (see below), that user is added to the Owners group for the new site collection, and is also added to the Site Administrators list. This user has full power over their MySite. To customize that is a bit difficult, but possible.
I created a Visio diagram that depicts the relationships between the pages, where profile information is used on them, and how the links between them interact.
Screenshot (click to download the diagram)
What happens when you browse to http://mysite/?
Whenever you browse to http://mysite/, you're redirected to http://mysite/personal/userid/default.aspx through a few steps:
-
http://mysite/default.aspx inherits from Microsoft.SharePoint.Portal.WebControls.MySiteHostHomePage. This assembly authorizes the user against the MySite shared service rights (can be enabled/disabled by users or groups), then emits an HttpResponse.Redirect to either /_layouts/MySite.aspx or /_layouts/AccessDenied.aspx, accordingly.
-
/_layouts/MySite.aspx inherits from Microsoft.SharePoint.Portal.WebControls.CreatePersonalSpace. This assembly examines the user profile property Personal site.
-
If the Personal site property is blank, CreatePersonalSpace creates a new MySite site collection for this user, then stores its relative URL (e.g. "/personal/userid/") in the Personal site property.
-
CreatePersonalSpace then emits an HttpResponse.Redirect to the URL in the Personal site property.
-
You arrive at http://mysite/personal/userid/default.aspx, where "mysite" is the URL of the web application hosting your MySites, and "userid" is your user id.
-
Note, other configurations could change this URL, such as the Personal Site Location ("personal") and the Site Naming Format (whether "userid" should include your domain.) These settings are found on the SSP Admin page "My Site settings."
Customizing MySite
Steve Peschka has the best information for customizing MySites, including how to set a custom master page automatically for all new MySites being created... this one's not obvious! Steve has a very clever approach that uploads an XML file to each new MySite, containing instructions on what should be modified. Then, a control in the custom master page reads the XML file and performs the customizations. He explains why this approach is necessary.
His XML spec for customizations provides several things you can do, such as removing/adding web parts and modifying QuickLaunch links. He doesn't provide a way to change the permissions of the owner... look for another blog posting from me on how to do that when you want to restrict the rights of each MySite's owner.
See also
To enable/disable MySites, Managing MySite Creation and Usage.
If MySites are disabled, Where is My Picture stored? What if MySites are off?
Many times it helps to see an overall comparison of SharePoint 2007 permissions. I assembled a matrix that shows lots of useful information that helps you understand how permission levels are related, and how they affect security trimming of Site Actions and Site Settings.
Screenshot (click to download the spreadsheet)
So, I'm not one to just post what I read on other blogs... but if you're a MOSS developer, you should definitely know about the Visual Studio Extensions for WSS 3.0, Version 1.1. This add-on for Visual Studio turbocharges your creation & management of Features and Solutions. A really big help for those new to MOSS development and those of us who are tired of some of the tedium of these administrative tasks. Go get this one!
Download: http://www.microsoft.com/downloads/details.aspx?FamilyID=3e1dcccd-1cca-433a-bb4d-97b96bf7ab63&displaylang=en
Often, a request comes to customize some of the text that SharePoint displays. And often, that text is stored in one of SharePoint's resource files, so it's just a matter of finding the right one. But I've noticed that Windows explorer doesn't do a very good job of searching inside *.resx files. In fact it behaves as though it just skips these files. Of course, you can open the resx files in Visual Studio to search them, but they appear in many different directories, so it can be a bit of a headache just to get them all opened.
After needing to do this for about the 30th time, I decided to make searchable copies of SharePoint's resx files... easy enough, just save them all as xml. For your convenience, here they are in one zip file.
Download: http://code.msdn.microsoft.com/SearchMossResources