Just Published on MSDN (5/17/2007)
Here is the rundown of Technical Articles, Visual How-to Screencasts, and their accompanying downloads published over the last couple of weeks on MSDN.
- Team-Based Development in Microsoft Office SharePoint Server 2007
Learn to properly conduct team-environment development of Microsoft Office SharePoint Server 2007 sites and assemblies (Web Parts, site templates, custom list templates), as well as develop Microsoft Office SharePoint Designer artifacts (master pages, workflows, CSS sheets). (13 printed pages)
- Upgrading an MCMS 2002 Application to SharePoint Server 2007 (Part 1 of 2)
Learn how to upgrade a Microsoft Content Management Server (MCMS) 2002 application to Microsoft Office SharePoint Server 2007 by using this step-by-step guide and the WoodGroveNet MCMS 2002 sample application. This article is part 1 of 2. (25 printed pages)
- Upgrading an MCMS 2002 Application to SharePoint Server 2007 (Part 2 of 2)
Learn how to upgrade a Microsoft Content Management Server (MCMS) 2002 application to Microsoft Office SharePoint Server 2007 by using this step-by-step guide and the WoodGroveNet MCMS 2002 sample application. This article is part 2 of 2. (35 printed pages)
Visual How-to Screencasts
Enabling Users to Act on LOB Data with Business Data Catalog Actions
Learn how to enable your users to act on line-of-business data by using Business Data Catalog Actions.
Activating Auditing Programmatically for a Single Document Library in Windows SharePoint Services 3.0
Microsoft Windows SharePoint Services 3.0 includes a powerful new infrastructure for auditing user access to pages, and document and list items. You can enable auditing for an entire site collection, but it can be more efficient to enable auditing with more granularity. For example, you might want to enable auditing for one specific list or document library. You can go even further and just enable auditing for one specific list item or one specific document.
Activating Auditing Programmatically for a Site Collection in Windows SharePoint Services 3.0
Microsoft Windows SharePoint Services 3.0 includes a powerful new infrastructure for auditing user access to list items, and documents and pages. In Windows SharePoint Services, auditing is configured on a site collection-by-site collection basis. It just takes a few lines of code to fully enable the auditing for an entire site collection. When you do this, Windows SharePoint Services writes an audit entry to its audit log each time a user views or modifies a list item, document, or site page.
Configuring IntelliSense with CAML files when developing for SharePoint 2007
When developing for Windows SharePoint Services 3.0 (WSS), you are often required to create and modify XML files that contain Collaborative Application Markup Language (CAML). It is recommended that you configure Visual Studio on your development workstation to reference a XML schema file named WSS.XSD so that IntelliSense works properly when working with CAML-based files.
Create a Custom HttpHandler in Windows SharePoint Services 3.0
ASP.NET programming supports the creation of custom HttpHandler components, which provide a flexible and efficient way to process requests that don't return standard HTML-based pages. For example, HttpHandler components are great for situations in which you want to return simple text, XML, or binary data to the user.
Although development techniques involving HttpHandler components are useful when creating standard ASP.NET applications, you should also see them as a valuable building block for building business solutions for Microsoft Windows SharePoint Services 3.0 and Office SharePoint Server 2007.
Creating a Feature for an Entry Control Block Item in Windows SharePoint Services 3.0
You can add a custom menu item for an entry control block to a list item or a document in Microsoft Windows SharePoint Services 3.0 by creating a Feature with a CustomAction element. In this way, you can add custom commands to the default SharePoint user interface. These menu commands allow users to perform custom operations on items and documents. For example, you can create a custom menu item for an entry control block for a list item or document that redirects the user to a custom application page. Use this as a starting point to create business solutions that provide an intuitive user interface to automate domain-specific tasks on list items and documents.
Creating a Feature for the Site Actions Menu in Windows SharePoint Services 3.0
You can add a custom menu item to the default Site Actions menu in Microsoft Windows SharePoint Services by creating a Feature with a CustomAction element. In this way, you can add custom commands to the default SharePoint user interface. These commands are available to users as they move between pages on a SharePoint site. When you create a Site Actions menu item, you can configure it to redirect the user to any URL. For example, you can redirect the user to another Web site. You can also redirect users to a custom application page that allows them either to see a custom display of data, or to perform custom operations on the content within the current site.
Creating a Solution Package in Windows SharePoint Services 3.0
Microsoft Windows SharePoint Services 3.0 introduces a deployment mechanism named "solution packages." A solution package is a CAB file with a .wsp file-name extension that contains all the files that must be deployed on the front-end Web server and a set of XML-based installation instructions. Windows SharePoint Services provides a rich infrastructure that simplifies deployment of solution packages in a Web farm environment.
Creating a Visual Studio Project for Windows SharePoint Services 3.0
Development for Microsoft Windows SharePoint Services 3.0 often involves deploying custom source files into the WSS \TEMPLATE directory. It is helpful to create a Microsoft Visual Studio project with a directory structure that parallels the \TEMPLATE directory so you can automate copying your source files into the location required for deployment and testing.
Creating an Application Page in Windows SharePoint Services 3.0
You can create custom application pages to add user interface components to a custom solution based on Microsoft Windows SharePoint Services 3.0. Unlike site pages (for example, default.aspx), a custom application page is deployed once per Web server and cannot be customized on a site-by-site basis. Application pages are based in the virtual _layouts directory. In addition, they are compiled into a single assembly DLL. They are also used across all sites within a server farm. For these reasons, they perform better than site pages. With application pages, you can also add inline code. With site pages, you cannot add inline code.
Displaying Data by Using the SPGridView Control in Windows SharePoint Services 3.0
When you create ASP.NET applications, you often need to display data in the format of rows and columns. Although you could create an HTML table by using code, you become much more productive by using server-side controls such as the GridView control introduced with Microsoft ASP.NET 2.0. The Microsoft Windows SharePoint Services platform provides a grid control named SPGridView that inherits from the ASP.NET GridView control. The SPGridView control provides a great alternative for displaying tabular data in SharePoint-based solutions.
Reading Entries from the Audit Log in Windows SharePoint Services 3.0
Microsoft Windows SharePoint Services 3.0 introduces a powerful new infrastructure for auditing user access to list items, documents, and pages. However, you must write custom code to take advantage of this auditing infrastructure because no default features utilize it. Some of the other Visual How-To topics show you how to enable auditing. Here you can learn how to retrieve information from the audit log so that you can display and report on user activity within a custom solution based on Windows SharePoint Services.
Reading ListId and ItemId from an Application Page in Windows SharePoint Services 3.0
In Microsoft Windows SharePoint Services 3.0, you can create a menu item for an entry control block that redirects users to a custom application page. For example, the MSDN article Item-Level Auditing with SharePoint Server 2007 demonstrates how to provide each document within a document library with its own menu item in the entry control block. This menu item redirects the user to a custom application page that displays the audit history for that particular document.
When a user clicks a menu item in the entry control block, it runs an application page. The code behind the application page typically must program against the list item or document that supplied the menu item. To do this, the application page must be able to identify the list item or document. Windows SharePoint Services does this by passing the information that identifies the list item or document to the application page in a query string. The page uses this information within the page-initialization code to create an SPListItem object and its containing SPList object.
Running Commands with Elevated Privileges in Windows SharePoint Services 3.0
Microsoft Windows SharePoint Services uses impersonation so that code running within a Web Part or behind a custom application page executes with the identity and permissions of the current user. In the vast majority of cases, this behavior is exactly what you want because it prevents standard users from being able to execute commands or see information that is intended only for privileged users such as a site administrator. However, occasionally your code must call restricted methods within the Windows SharePoint Services object model even though the request is initiated by a nonprivileged user. In such cases you must be able to elevate the privilege of your code as it executes on the Web server.
Writing Custom Entries to the Audit Log in Windows SharePoint Services 3.0
Microsoft Windows SharePoint Services provides an auditing facility that allows you to see the actions users take within the context of a site collection. Examples of user actions that you can audit automatically include viewing, updating, and deleting list items and documents, as well as viewing site pages. One important limitation of the built-in auditing facility is that it cannot audit access to application pages that are deployed within the \LAYOUTS directory.
If you want to audit the actions of users as they view your custom application pages, you must add code that writes custom audit entries into the Windows SharePoint Services audit log. You can write custom audit entries within the context of any auditable object, such as those of type SPSite, SPWeb, SPList, and SPListItem.