Application Pages in SharePoint

Application pages allow you to create custom screens in SharePoint and make them available at any site level, similar to the accessdenied.aspx and error.aspx that come out of the box with SharePoint. To create an application page, follow the article by Ted Pattison to get the minimal code that is needed in an application page.

Once you have the page built you place it in the 12 hive in the Layouts folder. To access your cuastom page you then navigate to a site (i.e. http://sharepointserver/site/_layouts/nameofcustompage.aspx. This will display your custom page. You can access it at any level of your site.

Application pages provide an excellent way to add custom code to your site and can be debugged by attaching to the W3WP process on the SharePoint server that matches the AppId of the site you want.

Minimal Master Page

One of the things I frequently find myself doing is creating a master page for some custom layout. There are many controls that need to be on a master page or errors will be thrown by SharePoint. To make sure you have all the controls the first time, Microsoft created an article with the code needed to create a minimal master page.

I use this article all the time and thought other people would like to have a place to go instead of trying to figure out what controls are needed.

Additional Tools for SharePoint Development

Another tool that can aid in the development of SharePoint solutions is the SharePoint Developer Explorer, which allows you to see the structure of your SharePoint site in Visual Studio. For more information check out TheKid's site:

http://blog.thekid.me.uk/archive/2007/10/16/sharepoint-developer-explorer-visual-studio-add-in.aspx

Using Code Behind Files In WSS and MOSS

Andrew Connell did an excellent post on using code behind files in Windows SharePoint Services and Microsoft Office SharePoint Server. This is an important topic for anyone interested in SharePoint development.

http://www.andrewconnell.com/blog/articles/UsingCodeBehindFilesInSharePointSites.aspx

To Extend or Not to Extend - That is the Question

At one point or another in every SharePoint administrator's career there comes the point where they have to take an Intranet SharePoint deployment and allow Extranet or Internet access to it for other stakeholders of the organization. This is a simple enough process, the only trick is whether to use the built-in functionality to extend a web application or to simply add some alternate access mappings.



If you choose to use the Extend Web Application feature in SharePoint, which is located in Central Administration under Application Management -> SharePoint Web Application Management. Choose the Extend an existing Web application option. It will then ask you to choose a Web application to extend and then the same settings that are available when you create a Web application - the name of the IIS site, port, hostheader, path, authentication provider, allow anonymous, and whether to use SSL. Under the load balanced URL section there is a new item that says zone. This correlates to the IE zones and also to the alternate access mapping that SharePoint will create. The options are default, Intranet, Internet, Custom, and Extranet. When you click the ok button SharePoint will create the IIS site and will create the alternate access mapping automatically.



The second option is to go into the alternate access mappings yourself and add them. AAM is located in Central Administration ->Operations -> Global Configuration -> Alternate Access Mappings. You would simply select the Alternate Access Mapping Collection from the drop down and then click on the Edit Public URLs link. You then have the option of adding the URLs for each of the 5 zones. Then just click save and the alternate access mappings are added.



Either way will allow alternate access to your SharePoint site. The choice is yours.

Sharing Your Excel Spreadsheets

How many times have you run across the scenario where you have multiple people who need to access an Excel spreadsheet and all need to run calculations and run forecasts against the sheet. Most IT people know how hard it is to keep "one version of the truth" with multiple copies of spreadsheets floating around the office.

Microsoft attempts to combat this with MOSS 2007. In it is a feature called Excel Services. This service allows you to upload Excel spreadsheets to a trusted location and users can then access the spreadsheets from a browser or download them to their local machine.

To set up Excel Services you need to go to Central Admin and go to your shared services providers. Make sure that Excel Calculation Services is started. Then go to the Trusted file locations and add the location where you will be storing your excel spreadsheets. You can then upload files to that location. When you point your browser to the same location, the Excel Spreadsheet will load right in the browser and will allow limited functionality. You can also download the file to your local machine to have full Excel functionality.

Excel Services has an object model that allows you to do programming against the spreadsheet and include User Defined Functions (UDFs) to perform calculations in the sheet when it is rendered.

Excel Services promises to be a useful addition to MOSS.

NOTE: You need the full version of MOSS to use Excel Services. It is not available in WSS.

For more information on Excel Services.

Variations Make the World Go Round

The next few posts concern some recent finds when working with the variation mechanism in SharePoint. Variations allow for the quick creation of language sites and allow you to add workflow items for translators to translate the text and then submit the page for approval. An approver can then approve the page, where it will be available on the site. Variations work by creating a landing page in the top site which has some logic to determine the default language of the user's browser. If there is a variation with that culture set, then the user is redirected to that version of the site. If there is not a site with that culture, the user is sent to the default culture site. Each language is a subsite in the SharePoint hierarchy.

While the built-in landing page provides some very cool functionality, (to determine the users preferred browser language and direct them to the appropriate variation), what happens if you want to store the user's language preferences in a user profile or in a separate data store. Well you can modify the landing page and add your own logic to create the preferred action that you want.

This site demonstrates how to customize the landing page to pull data from a user profile to determine which variation the user should be sent to.

Integrating Line Of Business Data

In SharePoint you can easily integrate line of business (LOB) data into SharePoint for easy collaboration and searching. To integrate this data you will be using the Business Data Catalog. The official Microsoft documentation says that BDC allows for the integration of line of business without using code. Although this is mostly true, you will need a good understanding of XML to create the BDC definition. Note that BDC is only available in MOSS, not WSS. Once you have the BDC set up you can use the data in web parts, lists, search, and user profiles. The following site has some good examples of using the BDC, creating the definition, and tools to aid in the creation of the definition files. Believe me, you don't want to build the BDC definition from hand.

SharePoint 2007: BDC - The Business Data Catalog

Request to Run ActiveX control on MOSS Sites

Today I was passed an email about public-facing MOSS and WSS sites prompting users to run an ActiveX control on the page. The control wants to run name.dll which is used by the presence feature in WSS. There is a workaround until Microsoft can fix the issue. This article explains the issue in more depth and provides the workaround:

http://www.sharepointblogs.com/mossman/archive/2007/09/13/fixing-the-name-dll-activex-problem-the-mossman-way.aspx

This seems to be a sporadic issue. We have a couple of public-facing sites and one has been prompting users to run the ActiveX control and the other, which is a much more heavily trafficked site, has not prompted a single user to run the control. The only other difference is that one site has anonymous access turned on and this could be the key to this issue not appearing on that site.

List Template Types

We have been discussing various parts of features and solutions and how you can use them to efficiently build your SharePoint business solution. One of the most basic things is to create a list template that instances can base themselves on. To begin your list template feature you need to create a ListTemplate element. This element has many attributes that define your list. One of the most important of these is the Type attribute. In the MSDN documentation it states that this is

"Optional Integer. Provides a unique identifier for the template. This identifier must be unique within the feature, but need not be unique across all feature definitions and site definitions. It then lists the built in template types and the type of list that they correspond to:

100 - Custom List
101 - Document Library
102 - Survey
103 - Links List
104 - Announcements List
105 - Contacts List
106 - Events List
107 - Tasks List
108 - Discussion Board
109 - Picture Library
110 - Data Sources
111 - Site Template Gallery
113 - Web Part Gallery
114 - List Template Gallery
115 - XML Form Library
120 - Custom Grid for a list
200 - Meeting Series List
201 - Meeting Agenda List
202 - Meeting Attendees List
204 - Meeting Decisions List
207 - Meeting Objectives List
210 - Meeting Text box
211 - Meeting things to bring list
212 - Meeting Workspace Pages List
300 - Portal sites list
1100 - Issue Tracking
2002 - Personal Document Library
2003 - Private Document Library

It then states that this value corresponds to the Type attribute of the List element.

We have been having some problems with this actually working, though. We built out some lists using the Visual Studio extensions for WSS and we wanted to place some list event receivers on a specific list. Well according to the extensions you should be able to do this by adding the event receivers to the .cs files for that list instance. We tried that and the event receivers were on every custom list. So we poked into the XML for the list instances and found that all of them were using type 100 or (Custom list). So we tried changing them to a different numbers in the 800 range, such as 800, 801, 802, etc. When we tried to deploy the new solution and check the list we received an HRESULT error, which most people know are some of the most unhelpful errors you can get in SharePoint. So we changed the numbers back and then re-deployed and the lists worked fine again.

The documentation says that it needs to be a unique integer across the feature. All of ours were and yet they did not work. If anyone has more insight as to how these list templates really work, feel free to leave a comment explaining them.

Release of SP1 for WSS 3.0 and MOSS 2007

Finally the release of SP1 for WSS 3.0 and MOSS 2007 is out! There are many hotfixes rolled into this service pack as well as some new functionality and stsadm commands. You should read the following post about how to apply the service pack.