How do we do SharePoint development, including TFS integration?

There’s lot of information available concerning development processes, automated builds and continuous integration in SharePoint development using Team Foundation Server, but unfortunately most of the information is in relatively high level or just concepts, but details are missing. It’s also fairly common misconception that setting for example automated build with TFS is difficult – it’s not.

Following chapters defines the practices we use in MCS Finland during development and for setting up the automated daily builds from TFS for enterprise projects. We will concentrate on the development process and setting up automated build process, but I’ll give some additional context from the project management point of view as well.

This content applies both SharePoint 2007 and 2010 development. There are minor changes and improvements with SharePoint 2010 development, which are pointed out.

In this blog post, we cover following topics

• Development process
• Visual Studio solution configuration
• TFS side configurations
• Automated testing environment setup

Development process

Following picture defines in high level the process we used for our enterprise projects. Actual details depends of course on the project size and project team. Actual process or methodology depends as well on the project, but process is always based on the agile approach with numerous iterations. Usually methodology used can be considered as adaptation from the SCRUM.

Iteration and production release count obviously depends on the project.

Visual Studio Solution configuration

There are few things to do in the Visual Studio Solution level to enable automated builds, if you use Visual Studio 2008 in development. By default Visual Studio 2008 does not understand the solution packaging concept, so we need to enable this by modifying VS project file. Also by modifying the project settings, we can improve our development experience.

In our case the standard VS2008 project structure usually looks something like following.  There’s few things to notice from the solution structure.

• Code is divided to multiple projects based on their usage models
  • ApplicationLogic – contains business logic of the project, including all actual code manipulating data of the lists etc. If patterns and practices models are used, services, repositories etc. are placed here as well.
  • Data – this is project for the data objects, which are used to transfer information between different solution layers. For easy manipulation in the UI layer, all code is transferred to data objects, rather then transferring actual SharePoint objects. This also helps in unit testing.
  • FeatureReceivers – this project has the custom feature receiver code. Code is separated, since feature receivers have to be placed to GAC in every deployment scenario.
  • Resources – this project contains the 12 hive files
  • Solution.Assemblies – project to create the *.Assemblies.wsp solution package
  • Solution.Resources – project to create the *.Resources.wsp solution package
  • Web.UI – Project containing all the code for web parts, web controls, http modules and code behinds for application pages
• As you see, there’s actually two projects, which are used to generate solution packages. One for the resources (stuff to goes to 12 hive) and one for the actual assemblies. This is controversy approach also in our team, but if the assemblies are separate from the resources, we can more easily and risk free, just update the actual code, without touching the xml files on disk.

For the projects, which are outputting solution packages (wsp files), we’ve configured new .targets file, which contains separate settings for Debug and Release configurations. The Target WSSSolution has been configured as the default target to these project by modifying project file.

Notice that output folder of the assemblies has been configured as “..\..\..\Binaries\Release\” in the Release configuration and that wsp package is also placed to the same folder using the above xml configuration. This is same relative path to folder what’s used by the TFS automated build process to output assemblies, before the whole folder is copied to drop location. Since the wsp package is also placed to this folder by default, it’s automatically copied to the drop location without any additional configurations. So we use the same relative path already in the development environments, so that we don’t need to change anything as part of the automated build process.

How to debug efficiently in VS2008? – This is quite common question, since in VS2008, there’s no native way debug the SharePoint customization efficiently, unless you’re using the VS extensions for WSS 3.0. Since the extensions were introduced quite late and they didn’t first support TFS integration fully, we haven’t got used to utilize them in our projects. This does not however mean that you shouldn't use them.

In our case, customers usually accept deployment of our assemblies to GAC, so don’t have to create CAS files for the deployments, which makes also the debugging little bit easier, since during development time, we can deploy our assemblies to the bin folder of the IIS application and start debugging without IIS recycles etc.

This means that we’ve setup the output folder of the Visual Studio projects to bin folder of the IIS application and configured the web application to fully trust the assemblies (<trust level="Full" originUrl="" /> in the web.config – not good practice if CAS files are used). To avoid unnecessary application pool recycles, we’ve also added additional AllowPartiallyTrustedCallers attribute to assembly, so that assemblies are loaded to IIS process memory runtime.

After these settings have been done, only thing left to do, is to attach to IIS process (w3wp.exe). To make this as efficient as possible, we use VS macro and short cut keys to establish the debug process. Basically this means that only thing we need to do to get the latest versions to development portal is to compile the code and press the shortcut in the Visual Studio. After you request the page from you browser, debugger get’s automatically attached and you can start debugging.

What kind of third party tools we use? – Actually none. Managing solution manifest and the ddf file is something which we do manually as part of the development process. Each person involved in the project has responsibility to keep the files in sync. Generally we aim to create stub versions of each control, web part and feature file in the first iterations of the project. Meaning that each feature file and template is already included in the package, even though it doesn’t do anything. Also each web part or control only write the purpose of the particular functionality – “This web part will provide the article comment functionality in later Iteration”. This way each iteration will just increase the functionalities, which are working as designed in technical architecture for customization document.

There’s lot of great third party tools available for the build process in the VS2008, but we have not decided to use them, since in the end manual updates do not take that long and if the process is automated, there’s no way to control what actually get’s packaged from VS structure. Meaning that if some features are not finalized yet for the solution package, we don’t need to add them to manifest and ddf.

How about SharePoint 2010 environment with VS2010? – When you develop SharePoint 2010 projects using Visual Studio 2010, solution package is by default compiled to the same output directories as the assemblies, so there’s no reasons for these additional configurations. Visual studio solution structure also looks quite different, since in VS2010, you’d place the code and 14 hive elements to same Visual Studio projects.

In SharePoint 2010 development, the common way to divide the files between the Visual Studio projects is based on the functionalities, not based on the file types. This means that for example the MySite functionalities are compiled to single solution package and portal and collaboration customizations to other packages. This model enables you a way to test and version the functionalities independently.

Debugging your customizations is extremely easy, since for all of the SharePoint customizations, this happens just by starting the debugging session directly from the Visual Studio IDE. Similar ways as for the 2007 environment, debugging happens in the same computer, where you develop your customizations. Target url for debugging is defined during the VS project creation or from the project properties.

How about SharePoint 2010 environment with VS2008? – This is definitely valid option and quite easy to establish (it’s only references). If you want to migrate your customizations as fast as possible to SharePoint 2010, this is most likely the temporary option you’ll use. In this case, you’ll have to modify the VS2008 project types as declared above. Since VS2010 however improve the productivity of the developers, we strongly suggest to migrate your code to VS2010.

VS2010 supports importing existing solution packages to your Visual Studio solution. This way you can relatively easily migrate your VS2008 package to VS2010. After importing, you’ll need to reconfigure the packaging model, which will require refactoring, since the Visual Studio 2010 solution structure is not total imitation from the 14 hive.

TFS side configurations

In the TFS side, all we need to do is create the build agent and the build definition for the project. This is relatively trivial process, but basically we are enabling the automated build using standard TFS side configurations. Since we’ve configured the solution package to be dropped to the same locations as the compiled assemblies (dll files either in Debug or in Release folder), we actually don’t need to do any additional steps or configure any additional msbuild settings of the build project.

• TFS 2008: A basic guide to Team Build 2008

Some things to remember when you setup the build server

• Ensure that you have the proper assemblies installed and/or available on the build server. Setup is dependent on the decencies on your code.
• Ensure that the build service is running using domain account, which has access to the team project, so that the build service can get the latest version from the source safe
• Setup share to the build server or any staging server to where the compiled builds are stored, including the solution package
• Remember to setup proper cleaning process for the automated builds, since each build will consume space – this can be controlled using the retention policy of the build definition file

Depending on your code and unit testing practices, you can also add unit testing as part of your code compilation. Since some of the SharePoint dependent code can be difficult to mock, this might be difficult or require third party tools.

Automated testing environment setup

TFS automated build only verifies that the code itself compiles, but there’s still additional tasks to be done to ensure that code can be deployed and that the actual use cases work as expected. Especially for the larger projects, we’ve created additional steps, which are used to imitate the customer installation of the customizations. This way after each automated build, we have similar upgraded version of the portal, that the customer would have. To automate this, we’ve added few scripts to be executed.

The following model also decreases the inefficient working time of the tester to setup the actual testing environment, before the actual functionalities can be tested. We can certainly test some of the functionalities using automated testing, but for larger projects, it has been fairly common to have dedicated tester.

In one of our centralized hyper-v servers, we’ve setup a scheduled batch file, which is executed after the automated build process. 

As you can see from the batch file content, we first solve the latest solution file, continue with snapshot modifications and as final step installs the build to the particular virtualized environment.

We use powershell to restore the status of the testing server to same status as in the production environment. This is done by using following powershell script, which restores the snapshot given as parameter to the script.

When this script has been executed, the virtualized environment is back online and the defined snapshot has been restored. Following step is to apply the actual build to the restored VM. For this the following script is used.

As you can see the script, we are copying the solution package from the TFS autobuild server to share located in the testing server (which was just started). After that we can execute the upgrade script on the testing server, which contains the project dependent script to upgrade the existing portal with the new version of the customizations.

By using these relatively simple scripts we now have clean and updated environment for testing every single day with all the latest customizations. Model obviously decreases the overall project costs, since we don’t need to spend time setting up the environments manually.

How to further improve the process?

After the testing environment has been setup, we can also improve even further the process. Common improvements would be to add web testing and load testing to this scenario. Due the extensive support for scripting, we can automate these to be included to the daily process. This would mean that after the testing environment has been setup, we start the automated web tests for use case validation and performance testing to ensure that new code has not dramatically decreased the performance.

Web testing is again relatively trivial task to do with the Visual Studio and it provides quick way to ensure that basic functionalities are still working as expected.

Performance testing uses the recorded web testing scripts and imitates larger load. Even though the development testing environment is not using same hardware as the production, we can do estimates and assumptions based on baseline tests.

Baseline testing means that we have made tests in the customer environment and in testing environment using same customizations. If the new version is decreasing test environment performance for 20%, we can assume that the result would be most likely the same in the production.

Improvements in SharePoint 2010 for the process

As mentioned already earlier in this post, when you develop customizations for the SharePoint 2010 with Visual Studio 2010, there’s native support to compile solution packages to the output folder of the Visual Studio project, so there’s no need for any msbuild script changes.

Other huge improvement is the native support for upgrade and versioning in the feature framework side. This will help to upgrade already existing portals and manage the versioning of the customizations. Traditionally in SharePoint 2007, this has been done with custom feature receivers, which modify the existing content. In SharePoint 2010, we have much more powerful tools to manage the portal lifecycle and to update the already existing content. Also the logging mechanism have been dramatically improved to help with customization troubleshooting, if deployments fails or something unexpected will happen.

We’ll release lot of new information concerning the SharePoint 2010 development in upcoming months, so stay tuned.

Summary

Setting up the standardized development process might seem like a large task, but when the environments and processes have been defined, it saves lot of resources to actual efficient project work. The processes we use for our enterprise projects (30-500-xxxx man day projects), is constantly evolving process, which is improved and changed based on the experiences from the projects.

Following people have also contributed to our standardized process: Jaakko Haakana, Juhani Lith, Janne Mattila, Tom Wik and Jukka Ylimutka.

Hopefully this was useful.

SharePoint 2010 – More public information available

Finally SharePoint 2010 information is publicly available after the release on SharePoint Conference past Monday. Since people participating to early adopters programs and for example MVPs, have had a change to work with the early builds for a while, there will be lot of new information available in the blogs during upcoming weeks.

Below is small collection of the most interesting blog posts and sites currently available.

Few links concerning the features available

• Microsoft Office SharePoint Server 2010 Virtual Pressroom
  • Lot of interesting videos and other content
• SharePoint 2010 introduction from Jeff Teper
• SharePoint Conference Keynotes – from Arpan Shah’s blog
• SharePoint 2010 informational site
• Improvements to the Core SharePoint Platform & How the Benefit SharePoint 2010 Web Content Management – Andrew Connell

Miscellaneous blog posts and articles

• SharePoint 2010 Developer Center
  • Introduction from SharePoint developer Documentation team blog
• Online SDK
• SharePoint 2010 in TechNet
• Visual Studio 2010 Tools for SharePoint Development – MSDN magazine – Steve Fox
• SharePoint 2010: Developer Tools Overview – harbar.net
• SharePoint 2010 Developer Dashboard – Bob Fox
• Single Server Complete Install of SharePoint 2010 using local accounts – Neil Hodgkinson
• SharePoint 2010 documentation and posters

As defined at the SharePoint team blog, public Beta available in November and during this time, you can start developing functionalities using Visual Studio 2010 Beta 2, which will contain all the necessary project types to support natively SharePoint 2010 development.

“Can I use Visual Studio 2010 project types for MOSS 2007 development?” – this has been fairly common question during the early training sessions. Theoretically it can be possible, if you update the references, but it’s not recommended. Natively VS2010 SharePoint tools supports SharePoint 2010 development

WCM enabled collaboration sites

Usually collaboration sites (team sites) and WCM functionalities (publishing sites) are seen as two totally separate functionalities provided by SharePoint. However by combining these both options, we can provide even more sophisticated functionalities.

One of the challenges in the team sites is the fact that there’s no easy way to store metadata in “site level”, since all of the stored information is managed in the lists. Wouldn’t it be nice, if we could dynamically list for example all of the team or project sites of one particular company division or group team sites based on the project manager assigned to the particular project site.

Usually this kind of requirements are solved by implementing a custom web part, which is used to store the “site level metadata” to database. This is good solution, but actually we can implement the same functionality just by utilizing out of the box functionalities.

Combining best of the both

• WCM provides us a way to store “site level” metadata. This can achieved by storing metadata information in the welcome page
  • This way we can utilize for example CQWP to list the content dynamically within site collections
• From team sites we can combine the great collaboration tools, which usually are not provided in WCM sites

Following chapters define one example usage model, which I prepared for development oriented trainings back in spring 2007. We have also used this same model successfully in multiple customer engagements.

Introduction to the solution

Following project catalog and project site functionalities are part of the more complex development methods solution, which demonstrates different possibilities of the SharePoint. Branding of the site has been done in matter of hours, so so don’t concentrate on the actual look and feel, rather to the functionalities. I didn’t want to spend too much time with CSS.

Project site

Requirement– Customer needs project sites, which should store also site level metadata. This information is used to aggregate site information in multiple places on the Intranet. Project manager, as the site owner, should be able to manipulate the site metadata to indicate progress of possible issues in the project.

Requirement– Customer wants to have project phases as the document libraries in the project site. These document libraries have different document templates.

Following steps defines the different features and functionalities developed to be able to provide the requested functionality.

1. Create a necessary site columns, which will be used to store the site specific metadata. Let’s create a feature, which defines the necessary site columns based on the requirements. Below is example of single site column required to store the organization division information.

2. Create a content type used for the welcome page of the project site. Since we are creating a publishing page content type, the content type is inherited from the out of the box Page content type and the document template is set as a specific aspx page.

3. Create necessary document content types used in the project site. Notice that we use the _cts –folder in the target definitions of the template upload (module element). Underneath this folder there will be specific content type folder created, when ever a new content type is provisioned to the site collection. This is good place to store the document templates, unless the templates are frequently updated (another story, another time…).

4. Create document libraries used in the project site, from where the document content types are provided. In the below image, we introduce a new document library template and create a new instance from it to be used to store documents in the Execute phase of the project. “Why new list template?” – If we only bind the document content types to default document library, the out of the box document template would be still available.

5. Bind the content types to the specific libraries. In the following image, we bind the specific document content types to the execute phase library. “Why aren’t we binding the content types directly in list template schema?” – this approach allows use to use the same document library template for multiple different instances and just bind the specific document templates depending on the instance.

6. Let’s not forget to bind the project welcome page content type to the pages library, so that the necessary fields will be provisioned to the list.

7. Now when the project site welcome page content type is available in the pages library, we can provision initial values for the site created. This can be done by setting the default.aspx page’s metadata appropriately as in the image below. Notice that we the the ContentType value as the content type declared earlier in the feature. We also define the initial status values to be “Green”.

8. We need to create a page layout, which is responsible of rendering the metadata information for the end users (I wont’ declared the detail steps to save some space). Now we can create the site definition used to provision the site. When the site is provisioned, we can see the initial values defined in the module above. “Why a custom site definition?” - If customer would like to utilize the oob team sites and other templates as they are, but they would also like to have this new definition available, custom definition is the only way to go. Since the WCM features are enabled, the site template option is not supported.

9. Site specific metadata can now be managed directly within the welcome page as long as the fields are rendered correctly in edit mode.

10. One advantage of this approach is also the possibility to utilize the field controls for content editing. This improves the content editing experience.

11. When the values have been updated and information is published, we have standardized site model for all of the project sites. This way the end users of the portal can easily see the key information of the specific project from the standardized place in the layout.

12. As part of the requirements we also created document libraries for each project phase and used content type binding to associate the specific document content types to the specific libraries. As an outcome we are providing different document templates from different document libraries. This way we make the document creation process more efficient and save time for the site end users.

Project catalog site

Requirement – Customer wants to list dynamically all of the project sites created underneath the particular catalog site. Aggregation should list the sites based on the organization division and the phase of the project. Only those sites on which the specific user has access to should be shown.

Solution is to use Content By Query Web parts (CQWP) as part of the site provisioning process and set the web part configuration values appropriately. Since the organization division and the project phase are stored as the metadata of the project site welcome page (created with specific content type), we can simply utilize the standard out of the box functionalities.

Now since we are using CQWP to aggregate the information, all the updates are automatically updated to the lists. Out of the box Site Directory does provide similar functionalities, but the list is not dynamically updated and the information is not stored in the specific site, so that the site owner (for example project manager) could not update the information.

Requirement– Only project sites should be created underneath the project catalog site.

Define the publishing features appropriately, so that only the project site is visible in the Create Site functionality.

Requirement– Customer wants indicate possible issues in the project sites for the managers based on the status updated by the project manager.

Luckily we had three status indications stored to the the metadata of the sites, which we can utilize. Let’s also create a audience for the managers and show the web part only to those persons, whoe belongs to it. Below is the picture to show dynamically those sites, which have any of the status metadata values selected as “red”.

Putting it all together

Of course all of the functionalities are packaged to the solution package  (wsp-file), which can be used to reproduce the functionalities in any MOSS deployment. This means that we need to create the manifest file, which is used to explain the SharePoint the content of the customizations, as in what features, site definitions, assemblies, web parts etc are included in the solution.

As addition to the manifest file, we need to create the ddf-file which is used when the functionalities are packaged to the solution package.

After this, we can deploy the same functionalities to any MOSS deployment and we can be sure that it works identically as in the development environment.

Independent site collections

Example design declared in this article works when the project sites are created to same site collection as the project catalog site. This has both advantages and disadvantages. One common design is the have the individual team sites created as own site collection. Also in this case, the WCM features enhance the functionality. If the site metadata information would be stored to external database, we’d have to create custom search functionality.

Since the “site metadata” is stored to welcome page based on content type, we can create managed properties of the information stored. Managed properties can then be directly utilized in the search results and we can provide same user experience as in example declared in this article.

Possible enhancements

There are multiple different ways to improve the defined functionality. Here’s few simple ideas.

1. Site approval – since we are utilizing the WCM functionalities, we could easily attach site approval process before the site would be visible for other portal users. By using minor versioning in the pages library, the site would not be visible for other persons than the site owners before the site is published as a major version. For the publishing process, we can specify any kind of workflow.

2. PKI values for the status - To indicate the project status more efficiently, we could create a custom field control, which renders the status values using traffic lights in the project site. For the catalog site, this is even more easier, since we can do conditional rendering in the xslt used by the CQWP. This way we could extremely easily create a list of all projects in organization and indicate their status using traffic light model.

WCM functionalities provides us numerous different functionalities, so you can easily invent more possibilities.

Considerations

“Why would I create standard team sites, rather than WCM enabled collaboration sites?” – good question. If the requirements can be met with more simplified solution, like feature stapling to out of the box team sites, than there’s no reason to enable WCM in team sites. If you need to provide more enhanced functionalities, enabling the WCM functionalities might just be the solution you are looking for.

“I use database to store the metadata values of the site, is this bad solution?” -  No, but remember to consider he overall consequences of your architecture choice. The solution to choose always depends on the requirements and functionalities to be provided. The downside of the database based model is however the fact that the metadata is not stored within the site and therefore we need to do additional work to ensure that the values are in sync. Also the database based model requires additional work on the operational point of view in sense of disaster recovery and maintenance. The WCM based model keeps the metadata in the site and even though the site location in the hierarchy would be changed, the metadata would be intact, since it’s stored as part of the site.

Hopefully this was useful.

Internet facing MOSS sites without content deployment

Lately there has been quite a lot of discussions concerning Internet facing MOSS sites and content deployment. Quite often there’s misconception that MOSS cannot be used as Internet facing platform without separate authoring farm and utilizing content deployment. Assumption is understandable, but completely wrong.

By utilizing possibility to have multiple zones for single SharePoint application, we can setup an environment, which is can be accessed by both anonymous users from Internet and content editors from corporate network using windows authentication.

Conceptual model

Zone in the SharePoint basically means different access points to access the same content. Each of these access points can have their individual configuration for the network and for the authentication. When we create a new zone, we actually create new IIS application, which is pointing to the same SharePoint application.

This model is often used in extranet scenarios, where the external users are authenticated using forms based authentication (FBA) and internal users are authenticated using windows authentication (NTLM). Same model can of course be used to provide content editing functionality for Internet facing site.

Following picture defines the elements more detailed.

Infrastructure architecture

Following picture defines the model in infrastructure level. There are multiple different variations of this kind of setup depending on the network policies and possibilities. Each of the elements and few possibilities are declared also in detail.

Considerations

Customization development and deployment

When separate staging or authoring farm is used, there’s more detailed processes to follow to keep the farms in sync, so that the content publishing work properly. In this option, there’s only one farm, so the deployment practices are more simplified (separate QA farm of course though recommended).

Other advance on the single farm setup is more simplified possibilities for custom solutions. Let’s have an example concerning simple feedback functionality.

• Objective – Collect feedback from end users by providing a simple form for information entry. Store the sent feedback to secure list in SharePoint, which can only access the web masters.
• Single farm with Zones – Create feedback list to the root web and setup the access control appropriately to it. Use elevated privileges in the custom form to write the feedback to the list. Web masters can access the list directly using the NTLM zone.
• Separate authoring farm – Since the content in the internet facing farm should not be updated for proper content publishing to work, we need to implement the write back to the authoring farm using web services. Writing entries for single list is natively supported, but especially little bit more complicated solutions increase the costs of the customizations.

Management

Since there’s only one farm to manage and monitor, the overall costs of the MOSS deployment are considerable smaller than having two farms. Also keeping the separate farms in sync is more complex than having single farm to configure. Model also decreases the storage requirements, since there’s no duplications concerning the databases of the individual MOSS farms.

Security

All the concepts declared in this article are dependent on the network configurations and security settings. Especially when we are exposing the services to the Internet, we really need to ensure that the network and farm is properly configured.

Also all the customizations developed have to follow the security recommendations so that any sensitive information is not exposed.

Content editing

Since publishing of the content is instant when the Publish –button is clicked, the content can be easily modified and managed. There’s no delays of getting the information released to the internet, except the possible caching configurations.

It’s of course important to notice the model in prepared training mater, like instructing the content editors to use relative addresses for resources, like images and for the links within the portal.

Real life experiences

We have used this model in multiple Internet facing sites during past few years successfully. Administrators have been pleased on the fact that there’s only one farm to manage and monitor, content editors have been pleased on the simplified model of authoring the content and generally customer directors have been pleased on the fact that the model saves investments done to hardware and to the possible customization.

Hopefully this provides more insight on the flexibility of the SharePoint and for the different possibilities it provides. Each enterprise architecture is independent and they all have their own environmental characters. Therefore the guidance provided from TechNet or from numerous blogs should be always adapt to specific engagement.

Office 14 for Web

This was so cool video, that I had to publish the link. Pretty interesting functionalities are coming up.

• http://channel9.msdn.com/posts/PDCNews/First-Look-Office-14-for-Web/

Caribbean English and SharePoint - localization techniques for WCM sites

This was so interesting, that I had to share it more widely... I'm working with one global customer concerning Internet facing MOSS site, which will eventually have more than 50 local sites within their own languages (including the corporate sites in multiple languages). Translation of the labels used in the sites are based on standard RESX handling, without any custom resource providers.

So basically as part of the solution deployment, the resx files are distributed to app_GlobalResources folder of IIS application in each WFE (requires some extra effort to be automated during deployment, but that's a separate story). The RESX files are not included in to the assemblies to provide more flexible way of updating just the translations without any other changes.

As part of the following releases, there was a requirement to generate the translations for the Caribbean English. You might wonder the business case, but there are certain phrases, which should be translated differently as for the US... similar way as there's different translations for UK. For initial testing, the RESX file with the correct culture information (en-CB) was created. When the file was introduced to the application, whole application came down with following error message.

Compilation Error
Description: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.
Compiler Error Message: CS0101: The namespace 'Resources' already contains a definition for 'CUSTOMER'

Well... that's interesting, since based on the .NET 2.0 documentation, the en-CB is officially supported locale. I did little bit more digging on the case and found out that there's actually a KB article released concerning issues with few locale codes, if certain security fix has been installed. KB article defines that for example in this case, the locale should be actually en-029. After changing the RESX file name correctly, everything started working again and translations were successful.

Improving the translation logic

Obviously the situation declared above was extremely scary. You can pull down the whole farm just by providing wrongly named RESX files. That's not good at all. Actually there's similar implications when the RESX file contains duplicate keys etc. It's of course clear mistake in the RESX, but the fact that the farm will be dropped to it's knees, is simply extremely scary. In our case, we luckily had strict process of getting the new files published in the farm (similar as declared here), so this didn't cause any catastrophic issues to production.

What can you do? - ASP.net provider model to rescue... since we can extend or change the default asp.net functionalities, we can write our own resource provider to manage the different translations. Of course the requirement of having custom provider to be written depends on the requirements for the project - especially on the high availability sense. Depending on the requirements and implementation, you can also define your own logic concerning fall back mechanisms and duplicate keys etc. etc. etc. More information on the resource provider can be found from the following MSDN article.

• MSDN - Extending the ASP.NET 2.0 Resource-Provider Model

This approach also provides more flexible ways to provide the translations. By creating a custom resource provider, we could also fairly easily provide UI to update the translations directly for example from the site settings page of the particular country sites. This way the maintenance of the labels can be more easily delegated and managed by the web masters of the particular country sites.

Hopefully this was useful.

Project planning and application lifecycle management

One of the most important and often overlooked thing to cover in planning phase of the projects is the application lifecycle management (ALM) for upcoming portal. In this context I don't mean just the lifecycle management for the customizations, rather for the full process and environments. Every single project done with SharePoint technologies (WSS/MOSS), should define the clear rules and practices to manage the process as early as possible.

By setting the ground rules immediately in the planning phase of the project, you can take them into account during the technical planning of the deployment and of course also in the operational planning. Following image and table defines one example process, which follows the continuous integration model for SharePoint development (Continuous integration in MOSS development using TFS).

Following table defines the steps and phases one-by-one.

Considerations

Following chapters defines few points to consider when the full process is planned. I also want to raise few pointers, which I have personally run into in multiple partners and customers.

Are the code and SharePoint artifacts in safe place?

It should be clear that the all of the customizations developed for SharePoint portal are stored in some source control system, like Team Foundation Server. You don't want be in situation where the customization are gone, due failure in single laptop or desktop. Also consider and ensure that the source control system is in safe hands. If there's critical issues in the production, which requires instant code level fix to be deployed, you need to ensure that the source control is up and running.

Basically this means that the source control system should be high available or at least there's a backup plan to access the source code in timely fashion, so for example possible SLA's can be achieved.

Is the process high available?

We need to go through the steps in the process to ensure that there's no single point of failure in the process. Technical failures can be fairly easily identified, but we also need to consider the steps, which require human intervention. You don't want to be dependent from single persons, which could compromise the environment for example during summer vacation. There needs to be a back up person for each critical responsibility, with sufficient knowledge concerning the possible tasks to be done.

Is there clear model to update the customizations?

Setting up the initial version of the portal is quite straight forward, but the possible updated versions have to be carefully designed. It's quite common that after the initial version, there will be additional functionalities included in the portal. At some customers, there are quarterly releases, which enhance the functionalities provided for the end users by introducing new possibilities and options. If the upgrading model is not clear before the initial customizations are deployed, life can get complicated. Can we use the in-place upgrade of the solution packages? Does the end users use SharePoint designer in production? Every decision has it's effect and there for we need to ensure the model already in the planning phase.

Personally I've seen way too many SharePoint deployments, which have been build up nicely, but when we need to update any of the customizations, the life get's over complicated.

Is the customization deployment model scalable?

The usage of the solution package in deployment of the customizations can be considered as the de-facto way of deploying ANY customizations to the portal. By using solution packages we can ensure that in case of increased load for the MOSS farm, we can scale the farm out, by adding additional servers. If the deployments are done manually, there's too huge risk for human errors and the servers won't be in-sync. Manual deployment would require also huge amounts of additional actions to be conducted when the new server is introduced to the farm.

Summary

I listed only few pointers to give you an idea of the things to cover in you project. Of course model and required processes is fully dependent on the scale of the deployment. If you only use closely out of the box SharePoint installations and the modifications are done using SharePoint Designer, you don't necessarily have to think through these kinds of things. For large scale projects, the models and processes have to be planned carefully. It's not rocket science and you should not over think the processes, but by planning a head, you can ensure the long running service, which will be definitely worth of investment.

MCM for SharePoint

Have you already completed the four MCTS certifications available for SharePoint and would like to have more challenges?

• MCTS: Windows SharePoint Services 3.0 – Configuration
• MCTS: Microsoft Windows SharePoint Services 3.0 – Application Development
• MCTS: Microsoft Office SharePoint Server 2007 – Configuration
• MCTS: Microsoft Office SharePoint Server 2007 ― Application Development

Would you like to distinct yourself as the real subject matter expert for SharePoint? Check the following links for more information concerning the upcoming Microsoft Certified Master (MCM) for SharePoint.

• Microsoft Certified Master Program
• Climbing the Ladder of Success with Microsoft Certification
• More on the Certified Master programs from me, Per, the program owner...
• So you think you qualify for the Microsoft Certified Master Program
• Live Meeting recording - https://www.livemeeting.com/cc/lmevents/view?id=MSFT073008AMlm&pw=ATT12125lm

Office SharePoint Server 2007 TechNet content released as .chm file

I just noticed that the SharePoint IT pro documentation team has released Office SharePoint Server 2007 TechNet content as a downloadable file, to be able to access the content also off-line (intercontinental flights etc.). According the announcement, the package will be updated in monthly. This is also good reference guidance, if you are in customer premises and want to verify something without access to the actual site.

• Blog entry - You asked for it, you got it: .chm builds of library content
• Download - Office SharePoint Server 2007 Technical Library in Compiled Help format

Continuous integration in MOSS development using TFS

I've been delivering quite a few technical training's during past year and one of the most discussed thing is the setup of the development environments for large scale projects. Especially large ISV's are really interested on the the practicalities of utilizing the TFS as the continuous integration (CI) and/or application lifecycle management (ALM) platform. For standard .net projects this has been the way to manage large projects and it's obvious that the investment and practices are wanted to be utilized also for the SharePoint based development.

Since SharePoint development differs quite a lot from the standard asp.net development, this has not been that straight forward. Following scenario is example done using Visual Studio and TFS, but the principles and practices can be easily adapted also for other continuous integration solutions, like the CruiseControl.NET (CCNet).

Setting up the Visual Studio solution for the TFS

Before the continuous integration can be setup in the TFS side, we need to configure the Visual Studio project correctly, so that when ever build is initialized, newly compiled solution package (.wsp) is  created. There are numerous blog entries available from the Internet including the detailed steps for this.

• MSDN - Automating Solution Package Creation for Windows SharePoint Services by Using MSBuild

Basically the idea is to configure the Visual Studio solution such away that each assembly is first compiled and then the solution package is compiled using the MakeCab.exe. For the VS solution where you have multiple projects, make sure that you have defined the project dependencies such away that that the actual solution package project (the one which output is the wsp file) is dependent on the assembly projects (outputs dll's). This ensures that the assembly projects are compiled, before the wsp package is generated.

Creating the auto build project for TFS

When the auto build process of the TFS has finalized by compiling the Visual Studio solution, we have received fully package solution package(s), which are ready to be deployed to any SharePoint server. Since the TFS is not aware of these kind of file types, it does not by default copy the wsp package to the drop location. This is not an issue, since we can modify little bit the build project to be able to initiate the portal recreation.  By opening the build project file (by default TFSBuild.proj located in the TeamBuildType/[build name]/ folder in TFS source control) and adding following xml elements, we make sure that the wsp package is also copied to the drop location and additional batch file (this case the rebuild.bat) is executed.

<Target Name="AfterCompile">
  <Copy SourceFiles="$(SolutionRoot)\[TFSProjectName]\[ProjectName]
                    \SolutionFiles\Package\[SolutionPackageName].wsp" 
        DestinationFolder="$(DropLocation)" />
  <Exec Command="C:\TFS\rebuild.bat" 
        WorkingDirectory="$(DropLocation)" />
</Target>

Note. Above example of using rebuild.bat is dependent on the fact that the SharePoint is located in the same server as where the build happens, which in most of the time, is not the case. Alternative solution is declared in the following chapter.

Really nice feature concerning the auto build is also the fact that operations and actions logged by the MakeCab are automatically included in the TFS auto build report, which is generated for each executed auto build. If there's anything wrong with your solution files (manifest, ddf etc.), the errors will be automatically logged here. Each executed build has it's own detailed information, from where you can access the build log as we can see from the following image.

Build log (BuildLog.txt) has huge amounts of details concerning the actions taken in particular build. All the MakeCab logged information is also included in the log for detailed analyses on the SharePoint solution package compilation.

Adding rebuild of the portal to scenario

When the wsp package has been created, it has to be of course deployed to the portal first, before it can be tested. This can accomplished manually, but it can also be automated, so that the portal is recreated automatically as part of the auto build process.

Personally I have done this few different ways. Initially I created a console application, which was executed as a scheduled task by the Windows OS. More convenient way to do the same would be to create few new extensions to the stsadm, which are responsible of setting up the environment, so that project members can access the latest version without any manual intervention. If the build server and SharePoint server are different servers (most likely the case), you can schedule the execution of the stsadm commands to batch file located in the server of the drop location.

Following defines one approach used. The tasks are dependent on the type of development and can be customized based on your requirements.

Objectives

1. Redeploy the new solution package to the farm - remove any previous versions, if exists
2. Recreate the portal hierarchy using portal site definitions
3. Define access to the newly created hierarchy for the project managers and testers

For these objectives, I created following stsadm extensions, which are sequentially processed. These commands access the farm using object model. By default the stsadm provides already similar functionalities, but by creating my own commands, I can easily improve and/or add any actions to be deployed as part of the auto build process.

Full scenario for continuous integration

Following image defines the key steps for the continuous integration within the SharePoint development. This model can be considered as the development time process for the project.

Following table defines the steps and phases one-by-one.

Possibilities to test and verify the provided functionalities in the development integration server depend heavily on the type of the solution to build. In case declared above, complete custom site definitions with initial configuration of custom web parts are included and there for when the portal site definition is used to create the structures, new functionalities are directly visible in the portal.

On the other hand, it's quite common that you are developing functionalities, which are associated to the out-of-the-box site definitions using site stapling techniques. In these kind of projects, the new functionalities would be available, as long as you create the definitions, on which the stapling has been added.

Even though you would be developing only few custom web parts, by utilizing the deployment model as declared above, you could verify the deployment packages for your project and test the web parts in the environment. If you are only adding few new web parts to out-of-the-box portal, you might want to consider automated activation of your custom features, which deploys the .webpart files to the portal. This way the tester(s) could verify the functionalities by adding new web parts to the portal using standard web part picker.

SharePoint artifact development

One of the thing to consider when setting up the project is the storage location of the SharePoint artifacts. Even though SharePoint provides version control for artifacts it stores, it cannot be considered as a actual source control system. Especially if the development is done by ISV, which is the most common case, it's good to have the source code including the artifacts in sync in the source code system (like TFS) to be able to label the actual releases of the developed features. Consider the practicalities to update your customizations from version 1.0 to 2.0 (I'll write later practices for version handling of your SharePoint project).

Artifact development on the ISV side can of course utilize the standard SharePoint tools, like SharePoint Designer, which increase the productivity during the initial creation of the functionalities. There's however no easily way to sync the artifacts from SharePoint to the Visual Studio package responsible of the encapsulating the solution packages. Whenever the development for particular artifact is finalized, it can be however copied to the package manually. This way for example the master page developer, can first finalize and verify the functionalities in her/his own virtualized environment and provide versions to the official solution package when appropriate.

Real life experiences

I initially created this process and the necessary configurations for one enterprise project, which started July 2007, where I was acting as the technical lead for the infrastructure architecture and for the customized development (at the time project started developers from ISV didn't have that much experience on the customization models). Overall amount of developers in the project was up to seven persons and since the development happened at customer premises, the daily builds provided easy way for the customer representatives to follow the progress and give instant feedback whenever required.

Similar setup would be however extremely useful for also any ISV, which does SharePoint development. Since the recommended deployment method for any customizations in the SharePoint landscape is to use solution packages, this process would be useful to any development project, no matter the amount of the customizations (from one web part to enterprise projects with tens of developers).

One additional advantages from automation came as a surprise during the project - or initially it was not foreseen. One of the guidelines we kept in the project was to utilize immediately fresh copy of the virtualized environments, if unexplained errors were encountered during development, that could not be solved in timely fashion. By utilizing the same process as for the auto build, we could recreate the full portal for the development environment from scratch (huge WCM portal) just by running the predefined batch files. This decreased the time required for setting up the development environments with latest build and there for saved project resources for actual activities to be completed.

Summary & more information

Utilization of continuous integration practices within the SharePoint development projects provides fairly easy way to increase the quality of the delivered functionalities. The process might first seem difficult, but when the initial configurations and actions have been completed, process can be reproduced easily to any number of projects.

Links to the concepts defined in this blog post

• Overview of Team Foundation Build
• How to: Extend the STSADM Utility
• SharePoint Solutions Overview
• Automating Solution Package Creation for Windows SharePoint Services by Using MSBuild

I'll write more guidelines concerning the ALM (Application Lifecycle Management) and other project practices for SharePoint development in upcoming posts.

Define Central Administration database to use in MOSS installation

By default when you install new MOSS/WSS farm to your environment, the content database for Central Administration application is renamed automatically using standard prefix (SharePoint_AdminContent_) and randomly generated GUID to avoid any problems if there's multiple MOSS farms installed using the same SQL Server.

If there's only one MOSS farm installed using the same SQL Server, you can quite easily identity the content database for the Central Administration web application, but especially if you have multiple MOSS farms utilizing the same SQL Server cluster, you might have difficulties to identity for example the Internet MOSS farm admin database, if the extranet farm is installed on the same server.

Usually also the companies hosting the databases would like to know the exact name of all the databases created as part of the installation process before hand, so that they can establish the necessary operational activities (backups etc.).

Solution for the naming issue is quite simple, but it has to be done before the actual MOSS farm installation is finalized, meaning before the actual MOSS farm databases are created using configuration wizard. After running the setup.exe, close the configuration wizard and move to the folder where the psconfig tool exists. This is the same folder where stsadm tool is located and by default the path is c:\program files\common files\microsoft shared\web server extensions\12\bin.

Execute the following from the command line (change the values to the correct ones to use in your environment...especially the farm account details)

Note. Make sure that the account you are using has the sufficient access rights to the database server as declared in Technet.

When the configuration is ended, the configuration database (this case the MOSS_Config) has been created to SQL Server (in this case to server servername) and you can restart the configuration wizard. From the wizard you can notice that the initial values have been already set and the server has already been attached to the newly created MOSS farm.

At this stage you can do the traditional next-next-next installation, since all the required information already has been configured. When the configuration is completed, the admin database you defined in the psconfig command has been created to the SQL Server and the Central Administration is automatically started.

Interesting governance and training material for SharePoint

I'm currently working in two large MOSS project (Global Intranet & Internet facing site) where there are requirements to define the governance models and organize training for the end users. It's quote common that companies do not realize the requirements in this area in time and when the projects are already in finalization phase, this causes huge fuzz... Even though the issue was raised immediately when the projects start... well nevertheless... Here's few extremely important links to material which are useful for every single MOSS project out there.

I'm not anymore even counting the times on when the customer have been amazed that Microsoft is providing this kind of guidance and training material... Yes... we actually do also something else rather than only install the products / servers... especially with MOSS.

Governance and general guidance

• SharePoint Gear Up
  • http://sharepoint.microsoft.com/gearup
  • Huge amount of good materials concerning how to plan the overall project based on the SharePoint technologies.
• SharePoint Governance site at Technet
  • http://technet.microsoft.com/en-us/office/sharepointserver/bb507202.aspx
  • Excellent site including numerous links to relevant documents, guidance and information
• SharePoint Governance Checklist Guide
  • http://technet.microsoft.com/en-us/library/cc261826.aspx
  • Excellent checklist, which points what to be plan and decide as part of the governance planning
• SharePoint Governance and Manageability (Codeplex)
  • http://www.codeplex.com/governance
  • Code examples and tools to manage sites more easily
• Example governance plan
  • http://go.microsoft.com/fwlink/?LinkID=92333&clcid=0x409
  • Sample by Mark Wagner and Joel Oleson

Training material

Following downloads were also extremely interesting, especially the Training Portal Edition, since it can be customized based on the customer case. In large global projects it's extremely important to provide consistent and well planned training materials for the administrators and end users... especially if they don't have necessarily any previous experience on the SharePoint.

Microsoft Office SharePoint Server 2007 Training Standalone Edition

http://www.microsoft.com/downloads/details.aspx?FamilyId=7BB3A2A3-6A9F-49F4-84E8-FF3FB71046DF&displaylang=en

• Step-by-step through beginning to advanced features, including Collaboration, Business Processes and Forms, Portals and Personalization, Search, Business Intelligence and Enterprise Content Management.
• Includes videos, interactive tutorials, and articles.
• Accessed through your browser after you install the application on your personal computer.

Microsoft Office SharePoint Server 2007 Training Portal Edition

http://www.microsoft.com/downloads/details.aspx?FamilyId=673DC932-626A-4E59-9DCA-16D685600A51&displaylang=en

• Built on the Microsoft SharePoint Learning Kit,
• Designed for server administrators who want to help their end-users learn how to use the features of Microsoft Office SharePoint Server 2007.
• Step-by-step through beginning to advanced features, including Collaboration, Business Processes and Forms, Portals and Personalization, Search, Business Intelligence and Enterprise Content Management.
• Includes videos, interactive tutorials, and articles.
• The material is SCORM compliant.
• Easily add or remove training topics to fit your business needs.
• Includes a reporting function that allows an administrator/trainer to track learners’ completed training topics.
• You can customize the Training to fit the look and feel of your own Office SharePoint Server site.

Dev Days 2008 - Example solution package

I'm speaking in the MOSS development track for the whole day in Finland Dev Days on upcoming Thursday (13.3.2008). As part of the delivery I prepared Visual Studio Solution package, which is demonstrated in each of the sessions with a little bit different twist. If you are interested, the used solution package can be downloaded from my public folder  in SkyDrive. Below is direct link to the folder...

I'll write more information concerning the functionalities demonstrated on the VS solution on upcoming blog posts including instructions and guidelines to extend / modify the solution based on requirements in projects.

If you have any questions concerning the structures, feel free to add comments on this blog entry...

Create a WebCreated event of your own in onet.xml

I just delivered an internal MOSS IW Ramp course in Münich and we have some discussions concerning the onet.xml and how to modify the content of the sites, which have been created using custom code directly after site has been created. You are most likely aware that during site provisioning, there's no such event available as the WebCreated, which would be raised when the web creation based on onet.xml has been done. This is quite a huge limitation, but then again, there are quite good workarounds for this.

Possible workarounds

1. Create your own custom site definitions using browser and export that using WSS 3.0 Extensions for VS 2005. As part of the export process, the tools generate the necessary code and associations to be used. Unfortunately the extensions do not support WCM enabled sites, so it cannot be used in publishing sites.
2. Use ExecuteUrl element to redirect the user to custom aspx page after the site has been created to be able to customize the site. Your custom aspx page might be located under the _layouts folder and there for we can easily point to that one using the xml elements within the onet.xml.
3. Create the WebCreated event using the powerfull feature framework. I'll declare the steps below for more detailed information.

Steps for WebCreated event using feature receiver

Step-by-Step guide for manual creating of WebCreated event are the following:

1. Create feature to deploy the default.aspx to root of the site using Module events
2. Create feature with feature receiver class – This is used for the Site Created event
3. Create site definition, which does not have directly default.aspx, rather use the feature developed above
4. Set the order of the features so that the default.aspx feature is activated before the receiver feature
5. In feature receiver feature, access the default aspx page, for example access the web part manager of the welcome page using following code

Final words

This was extremely quick sample, but hopefully it's useful to you. I'll try to find some time to make more comprehensive example of this.

Controlling publishing features from onet.xml

In the previous post, I promised to try to find time to share additional information concerning the onet.xml and how it can be modified to control other properties of the MOSS site. It took a while, but here we go. Starting from this blog entry, I promise to be more active with writing new stuff to the blog.

This blog entry explains the different options when you configure the standard publishing features in onet.xml. If you are interested concerning the navigation options for the MOSS sites, check the previous post with details concerning the different options on configuring the navigation settings within the site.

Introduction

If you have created your own site definitions based on the out-of-the-box reference implementations, you have most likely noticed following feature and it's configuration options.

The feature ID defined in the onet.xml refers to the Publishing feature stored by default in the folder C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\Publishing. Feature.xml file for the feature looks like following.

<Feature Id="22A9EF51-737B-4ff2-9346-694633FE4416"
         Title="Publishing"
         Description="Enable Publishing in a web."
         Version="12.0.0.0"
         Scope="Web"
         Hidden="TRUE"
         DefaultResourceFile="core"
         ReceiverAssembly="Microsoft.SharePoint.Publishing, Version=12.0.0.0,
                                              Culture=neutral, PublicKeyToken=71e9bce111e9429c"
         ReceiverClass="Microsoft.SharePoint.Publishing.PublishingFeatureHandler"
         xmlns="http://schemas.microsoft.com/sharepoint/">
  <ElementManifests>
    ...
  </ElementManifests>
</Feature>

So when the site is created based on this site definition, the Microsoft.SharePoint.Publishing.PublishingFeatureHandler class is executed, which manipulates the sites settings using object model, based on the properties defined in the onet.xml. Unfortunately the class used in here is dotfuscated, so we can not check all the possibilities using Reflector. I'll cover the known properties and their meaning one-by-one with corresponding images from the UI, so you can easily figure out the different meaning and possibilities of each of the properties.

Master page setting

<Property Key="ChromeMasterUrl" 
   Value="~SiteCollection/_catalogs/masterpage/MBaseMaster.master"/>

This is the most commonly used property in the feature receiver. You can use it to change choose the master page to be applied to the newly created site. This property configures the WCM master page to be used for the aspx pages, which are based on some page layout and stored in the pages list of the particular site. In this example we set the MBaseMaster.master master page to be used in this particular site.

It's important to notice, that this setting is actually the same setting as the Site Master Page in the master page settings page. This does not have any affect for example for the list aspx pages, since those pages use the system master page by default. I'll write separate post concerning the system master page and how it can be changed from the onet.xml easily.

Welcome Page Url

<Property Key="WelcomePageUrl" 
    Value="$Resources:cmscore,List_Pages_UrlName;/default.aspx"/>

This property defines the welcome page to be used for the site. Welcome page means the page, where the user is redirected when the site's url is requested. By default when the sites url is requested (for example http://portal/site1/) we redirect the user to the default.aspx page, as in this example. Good example of the welcome page usage, it the Wiki sites. The Wiki site uses the welcome page setting to redirect the user directly to the wiki list stored in the site.

In user interface, the welcome page can be set using the Welcome page link, which can be found under the Look and feel section in the site settings page.

On the welcome page setting page, you can browse to the file you want using standard asset picker.

Page List Url

<Property Key="PagesListUrl" Value=""/>

You can use this property to define some other list to be used as the pages library. By default the WCM pages are stored under pages list (http://portal/site1/pages), but if you like, you can change the setting by adding the list name in to this property.

Available Web Templates

<Property Key="AvailableWebTemplates" 
     Value="*-Microsoft.Intranet.POC.Project#1"/>

This setting can be used to filter the site definitions to be shown in the Create Site page. So using this property, you can limit the different options to be shown to the site hierarchy manipulators. If you have multiple different site definitions used in your portal, the portal managers might have difficulties of understanding the different templates available. It's also important to realize that if there's multiple appications installed on the same MOSS farm, all of the installed site definitions are shown by default in the Create Site page, regardless of the application used..

So if property is left empty, all of the installed site definitions are available. Multiple templates can be configured to the property using following syntax. In this example there would be two different site definitions available.

<Property Key="AvailableWebTemplates" 
     Value="*-Microsoft.Intranet.POC.Generic#1;
            *-Microsoft.Intranet.POC.News#1;"/>

From user interface, you can configure the same setting from the Page layouts and site templates functionality found under the Look & Feel section of the Site Settings page.

Using this functionality, you can manually select the shown site definitions. In this case also, all of the site definitions installed on the MOSS farm are shown, regardless of the particular application.

Following image is from the Create Site page, when only one site definition is configured to be shown. In this case, we are under the Projects Catalog site, and based on the portal design, it's decided that you should only create Project sites under it.

Available Page Layouts

<Property Key="AvailablePageLayouts" 
   Value="~SiteCollection/_catalogs/masterpage/MGenericBodyOnly.aspx:
          ~SiteCollection/_catalogs/masterpage/MGenericImageLeft.aspx:
          ~SiteCollection/_catalogs/masterpage/MGenericImageRight.aspx:
          ~SiteCollection/_catalogs/masterpage/MGenericImageTop.aspx:
          ~SiteCollection/_catalogs/masterpage/MGenericLinks.aspx:
          ~SiteCollection/_catalogs/masterpage/MSectionPage.aspx"/>

This property is similar as the AvailableWebTemplates, but it applies on the page layout level. Using this property, you can filter the page layouts to be shown in the Create Page functionality. Since there might be tens of different page layouts created on on portal, it's convenient to filter the options to be shown for the portal editors. If you have multiple page layouts available for the particular site, the different layouts are lsited in the same property, but separated using colon.

From the user interface, the similar would be configured using the the Page layouts and site templates functionality found under the Look & Feel section of the Site Settings page.

So when the configuration has been done for the site and you select Create Page from the Site Actions menu, we can see only the configured page layouts to be shown.

Simple Publishing

<Property Key="SimplePublishing" Value="true" />

Possible values for this property are True / False. This actually affects on the approval functionality concerning the sites pages list... If property is set as false, the pages list has require approval setting activated and there for all of the changes done to the pages in the sites, have to be approved using separate process. If the property is set as true, the content is instantly published to the portal.

Final words

Using these settings and properties, you can fairly easily control the different publishing settings for the particular site. On the upcoming post, I'll declare the detailed steps to write a custom feature receiver to be able to configure also those properties, which are not by default available.

Hopefully this helps.