Michael Hofer - SharePoint Blog

SharePoint Wiki: Create pages based on a template

mhofer1976 — Thu, 27 Sep 2007 08:13:00 GMT

Creating Wiki-Pages from a Template

To make Wiki pages look uniform, it would be handy if there was always the same template used when the pages are created. Unfortunately, WSS 3.0/MOSS 2007 doesn’t support this functionality (yet). The below paragraphs show the concept on how to achieve this functionality. Neither the code nor the configuration steps described are suitable for a production environment – they are just the proof-of-concept that it is possible. Adopt it freely!

The configuration part

1. Create a WIKI site

2. Create a Custom List called something like “Page Templates”

3. Add a custom column “Template” and make it multi-line rich-text including pictures etc.

4. Now create your HTML Template.

5. Copy your HTML (only the part inside the <body> of course) and add an entry in your custom list. In my example, the title is “Wikipedia” and in the “Template Column” switch to HTML view and paste your HTML Teplate

6. If your template needs a separate stylesheet, you must proceed like with any other stylesheet in MOSS (and make sure it doesn’t interfere with the standard styles so your layout gets corrupted…):

a. Upload the style sheet to the appropriate location in the Styles Library

b. Add a link to the style-sheet to the master page (Example: <SharePoint:CssRegistration name="<% $SPUrl:~sitecollection/Style Library/wikipedia_common.css %>" runat="server"/>)

The development part

Before I show the development steps this warning: This is a quick’n’dirty approach in a development environment and you mustn’t change standard MOSS-files! If you want to use this in a real environment, create a custom site definition where the Wiki Pages list doesn’t point to _layouts/CreateWebPage.aspx but to your own page which is deployed with your custom site definition. However, the scope of this instruction is only to show how it is supposed to work. Please keep this also in mind when looking at the code!

1. Create a new class-library

2. Make sure it will be signed

3. Add two references:

a. Microsoft.SharePoint.dll (12\ISAPI)

b. Microsoft.SharePoint.ApplicationPages.dll (\12\CONFIG\BIN)

4. Create your class inheriting from CreateNewWeb as shown in the code example. I guess the code is self-speaking:

using System;
using System.Web.UI;
using Microsoft.SharePoint.ApplicationPages;
using Microsoft.SharePoint.WebControls;
using Microsoft.SharePoint;

namespace Mho.SharePoint.Trials
{
    public class EnhancedCreateWebpage : CreateWebPage
    {
        protected ListFieldIterator listFieldIterator;
        protected string template;

public EnhancedCreateWebpage() { }

        protected override void OnPreRender(EventArgs e)
        {
            if (!this.Page.IsPostBack)
            {
                // Get the templates list
                SPList templatesList = this.listFieldIterator.Web.Lists["Page Templates"];
                if (TemplateSourceDirectory != null && templatesList.Items.Count > 0)
                {
                    // Just take the first template for demonstration
                    this.template = templatesList.Items[0]["Template"].ToString();
                }
                templatesList = null;

                this.FindRichTextControl(listFieldIterator);
            }
            base.OnPreRender(e);
        }

        private void FindRichTextControl(Control control)
        {
            foreach (Control childControl in control.Controls)
            {
                if (childControl.GetType().Equals(typeof(Microsoft.SharePoint.WebControls.RichTextField)))
                {
                    ((RichTextField)childControl).Value = this.template;
                    return;
                }
                this.FindRichTextControl(childControl);
            }
        }

}
}

5. Compile and deploy to the GAC

6. <Warning! See above paragraph – this is not supported!>

a. Open the file “12\TEMPLATE\LAYOUTS\CreateWebPage.aspx” (a backup could maybe be handy…)

b. Change the header to point to your assembly:
<%@ Assembly Name="Mho.SharePoint.Trials, Version=1.0.0.0, Culture=neutral, PublicKeyToken=261ba54b9846991b"%>

c. Set the correct class to inherit from
<%@ Page Language="C#" Inherits="Mho.SharePoint.Trials.EnhancedCreateWebpage"…

d. Add the name of the “ListFieldIterator” control you’ve used in the class code as its ID:
<SharePoint:ListFieldIterator ID="listFieldIterator"…

7. Recycle the application pool and try it out.

Posted on SharePoint Blogs

MOSS 2007 profile import using BDC with Single Sing-On: Permissions

mhofer1976 — Tue, 18 Sep 2007 13:42:00 GMT

If you want to extend your profiles with data not only coming from an LDAP source, but also from the BDC you have to be aware of some permission settings in order to prevent you from a severe headache. And even more when you connect to your external data source using the Single Sign-On service.

Configuring the import's custom datasource is pretty easy, so I won't get into this. But now comes what is not so obvious: How to set the permissions to make this work

Make sure you know the account on which the profiles are crawled. This is ususally the default content access account specified for the search (you cannot specifiy a special useraccount for the BDC custom datasource!
This account must be member of the group you've specified in the Single Sign-On settings page for the SSO application that is used in the BDC instance of your application definition.
Also, this account must have "Execute" rights on the BDC, the application and don't forget the instance itself! (I'm not so sure here, but there are these 3 levels of permission - instance is needed in any case!)
Make sure that this account hase the "Manage Audiences" right in "Personalization services permissions".

Uff... that's all. Now it should work. Happy trying

Posted on SharePoint Blogs

Sharepoint cannot authenticate to ISA Server - Resolved: Kerberos needed

mhofer1976 — Thu, 06 Sep 2007 12:37:00 GMT

This gave and gives me a hard time! Imagine MOSS 2007 running in a corporate intranet. Your requirement is to connect to datasources on the internet. There are various scenarios, the most common are to

Consume RSS Feeds using the RSSFeed webpart
Consume a WebService or Server-Side Script using the SharePoint Designer DataView Webpart

When using the DataView WebPart, you'll get the following error message when trying to show the data from the internet source:

“The server returned a non-specific error when trying to get data from the data source. …”

When connecting using the RSSFeed Webpart, the error message will be even less saying...

OK, what can we do? Make sure that you've set the proxy in the web.config of your SharePoint Site Collection, as documented by Microsoft here: http://support.microsoft.com/kb/923173

However, this might still not do the trick! The DataView WebPart still shows the same error message. However, the RSSFeed Webpart is this time a little bit more specific:

“ProxyAuthenticationRequired (The ISA Server requires authorization to fulfill the request…)"

So wat is the problem? It seems (and some other bloggers mentioned this explicitely) that SharePoint doesn not authenticate itself towards the ISA Server! The only solution to this problem is to allow requests from all the IP addresses of all SharePoint WFE Servers to pass through ISA! (wheew, I hear your customers start to question you louder than normal - at least this is what happened here ;))

Well, this is what I know so far and granting all requests of my SharePoint WFE's to pass through works just perfectly. I'll try to investigate in this a bit more internally and make sure that MOSS server-side authentication is included in Office 14...

UPDATE: This is a double-hop problem! If you use Kerberos authenticaion, there is no problem! Thanks smyttie!!!

Hope this helps some of you to save a lot of valuable time...

Posted on SharePoint Blogs

ActiveDirectory/LDAP: How to get the logon name of a user?

mhofer1976 — Wed, 08 Aug 2007 15:49:00 GMT

This post demonstrates how to construct the user logonname from an ActiveDirectory DirectoryEntry instance using C#.

Well, this time nothing about SharePoint! Wow! I've decided to post this little "How To" since I've encountered this problem already many times and spent always a heck of a time looking for an answer.

Situation

I have the DirectoryEntry instance representing a user-objectClass in ActiveDirectory and I want to get his/her Windows logonname using not the full qualified name, but "<domain>\<username>" format.

Solution

Use the "distinguishedName" property and extract the first "DN=xyz" information. This is tipically the domain name you are looking for. The username portion comes then easily from the "samaccountname" property.

Example:

string distinguishedName = ((string)entry.Properties["distinguishedName"].Value);
Regex regex = new Regex("(?<=DC=).+?(?=,)");
Match match = regex.Match(distinguishedName);
if (match.Success)
{
return string.Format("WinNT://{0}/{1}", match.Value.ToUpper(), entry.Properties["samaccountname"][0]);
}
else
...

Posted on SharePoint Blogs

Using the Business Data Catalog with Single Sign-On

mhofer1976 — Mon, 30 Jul 2007 21:06:00 GMT

Connecting the Business Data Catalog to a Microsoft SQL Server Database or any other ADO.NET based data source is an easy task when using Windows Credentials since the users own credentials or the application pool identity can be passed to the business application directly or a user/password combination can be used in the definition file (not recommended).

While it is for many reasons the best practice to use Windows Credentials to connect to any data source, there are sometimes scenarios where other authentication mechanisms have to be used. When connecting the Business Data Catalog to a Microsoft SQL Server Database using SQL Server authentication, user credentials must be transmitted using the Microsoft Single Sign-On Service.

MOSS 2007 includes an administrative interface to the Microsoft Single Sign-On service as well as an own pluggable Single Sign-On provider implementation. The following paragraphs describe how to setup and configure Single Sign-On and Business Data Catalog for SQL authentication-based data connections.

For reference, see [1].

Setup and configure Single Sign-On

General

Installing Single-Sign On capabilities require high attention on security. The following paragraphs describe a step-by-step approach using best practices for security configuration when installing Single Sign-On for the Microsoft Office System Server (MOSS) 2007.

The general reference on how to install and configure the Single Sign-On Service can be found in Technet (see [2]).

Step 1: Understanding the architecture

To use Single Sign-On, the Microsoft Single Sign-On service (SSOSrv) must be installed on all Microsoft Windows front-end Web servers in the farm.
SSOSrv must also be installed on all servers running Excel Services. If the Business Data Catalog search is used, SSOSrv must also be installed on the index server.
In addition, the Encryption-Key server has to be determined. This is always the first server in the system where the SSOSrv is started.

Step 2: Setting up security accounts and groups

In order to setup Single Sign-On, it is best practice to setup the following security accounts and groups:

SSO Service Account:

The account the Microsoft Single Sign-On Service is running on.
Must be a domain user account. It cannot be a group account.
Must be an Office SharePoint Server farm account.
Must be a member of the local Administrators group on the encryption-key server.
Must be a member of the Security Administrators role and db_creator role on the computer running Microsoft SQL Server.
Must be a member of the MOSS SSO Administrators Group.

MOSS SSO Administrators Group

Can configure MOSS SSO Server settings such as the database, MOSS SSO Application Definition Administrators or encryption keys.
Usually, these are the same administrators that also configure MOSS farm-level settings in Central Administration
Must be a Windows global group, cannot be a domain local group account or a distribution list.
Must be member of the Farm Administrators SPGroup on Central Administration.
The single sign-on service account must be a member of that group.
At least the farm administrator's account who is configuring Single Sign-On should be member of that group.
All group members must be local Administrators on the encryption-key server. Do not make this account a member of the local Administrators group on the encryption-key server.

MOSS SSO Application Definition Administrators Group

Can manage credentials of an enterprise application definition, including changing the password of a group enterprise application definition and changing or deleting credentials for an individual enterprise application definition.
Must be a Windows global group, cannot be a domain local group account or a distribution list.
Must be a member of the Reader SharePoint group on Central Administration.

Please note: It is crucial, that all requirements are met. If not, you will receive an error stating "You do not have the permission to perform this action" when setting up the MOSS SSO Server in Central Administration.

Step 3: Configuring the Single Sign-On Service

On the server, click Start, Control Panel, Administrative Tools, and then click Computer Management.
In the Computer Management console, expand Services and Applications, and then click Services.
Right-click Microsoft Single Sign-On Service, and then choose Properties.
On the General tab, change the Startup type to Automatic.
On the General tab, under Service Status, click Start.
Click OK to save your changes and close the Properties window.
Repeat steps 1 through 6 for each applicable server in the farm.

Step 4: Registering the Single Sign-On Service in MOSS

This step is not described in [2], however it performs some additional configurations on all servers where Single Sign-On will be enabled. For example, it adds the SSO Service Account to the IIS_WPG local group and configures the SSO Service (Step 3) to run under this account.

On Central Administration, on the top navigation bar, click Operations.
On the Operations page, in the Security Configuration section, click Service Accounts.
Choose Windows Service and the Single Sign-On Service.
Select Configurable for the account and enter the SSO Service Account by using the form domain\username.
Click OK to save your changes and close the Properties window.

Step 5: Setting up the MOSS Single Sign-On Server

You must open Central Administration on the computer that runs Office SharePoint Server 2007 to manage server settings for single sign-on.

On Central Administration, on the top navigation bar, click Operations.
On the Operations page, in the Security Configuration section, click Manage settings for single sign-on.
On the Manage Settings for Single Sign-On page, in the Server Settings section, click Manage server settings.
On the Manage Settings for Single Sign-On page, in the Account name box in the Single Sign-On Administrator Account section, type the MOSS SSO Administrators Group by using the form domain/group.
In the Enterprise Application Definition Administrator Account section, in the Account name box, type the MOSS Application Definition Administrators Group by using the form domain/group or domain/username.
In the Database Settings section, in the Server name box, type the NetBIOS name of the single sign-on database server (for example, computer_name or computer_name\SQL_Server_instance). Do not type the fully qualified domain name.
In the Database name box, enter the name of the single sign-on database server.
In the Time Out Settings section, in the Ticket time out (in minutes) box, type a value for how many minutes passes before a single sign-on ticket expires. The time-out should be long enough to last between the time that the ticket is issued and the time that the enterprise application redeems the ticket. Two minutes is the recommended value.
In the Delete audit log records older than (in days) box, type a value for how many days the audit log holds records before deleting them.
Click OK.

If you should get a "You do not have the permission to perform this action error" check the application log and make sure that all security requirements defined in step 2 are met.

Step 6: Creating the Application Definition

In the single sign-on environment, the back-end external data sources and systems are referred to as enterprise applications. For each enterprise application that Office SharePoint Server 2007 connects to, a corresponding enterprise application definition needs to be configured.

In order to connect to a Microsoft SQL Server database using SQL authentication a application definition has to be created in which the credentials of the SQL user will be stored.

On Central Administration, on the top navigation bar, click Operations.
On the Operations page, in the Security Configuration section, click Manage settings for single sign-on.
On the Manage Settings for Single Sign-On page, click Manage settings for enterprise application definitions.
Click on New Item
Enter a display name for the application in the Display Name box
Enter an application name for the application in the Application name box
In the "Field 1: Display Name" , enter "User ID" and set "Mask" to "No"
In the "Field 2: Display Name", enter "Password" and set "Mask" to "Yes"
Click OK
Back on the Manage Settings for Single Sign-On page, in the Enterprise Application Definition Settings section, click Manage account information for enterprise application definitions.
On the Manage Account Information for an Enterprise Application Definition page, in the Enterprise application definition list in the Account Information section, click the application definition for which you want to manage account information.
In the Group account name box, type the name of the group that is allowed access to the enterprise application.
In the Enterprise Application Definition section, select Update account information.
Click Set.
On the Provide Account Information page, in the Logon Information section, type the user name and password of the SQL user that will be used to connect to the Microsoft SQL Server database.
Click OK.

Configuration of the Business Data Catalog

Actually, there is no configuration to be done for the Business Data Catalog itself to interact with Single Sign-On. However, for every Application Definition where Single Sign-On is used, a LobSystemInstance node has to be added to the LobSystemInstances collection. Every LobSystemInstance specifies an "access point - in terms of connection and security information - to the LOB system, the Microsoft SQL Server database in this example scenario.

...
    <LobSystemInstance Name="Demo LOBDatabase">
      <Properties>
        <Property Name="AuthenticationMode" Type="System.String">RdbCredentials</Property>
        <Property Name="DatabaseAccessProvider" Type="System.String">SqlServer</Property>
        <Property Name="RdbConnection Data Source" Type="System.String">moss-sql01</Property>
        <Property Name="RdbConnection Initial Catalog" Type="System.String">SQLAuthDemo</Property>
        <Property Name="RdbConnection Integrated Security" Type="System.String">false</Property>
        <Property Name="RdbConnection Pooling" Type="System.String">false</Property>
        <Property Name="SsoApplicationId" Type="System.String">SQLAuthDemoSSOApp</Property>
        <Property Name="SsoProviderImplementation" Type="System.String">Microsoft.SharePoint.Portal.SingleSignon.SpsSsoProvider, Microsoft.SharePoint.Portal.SingleSignon, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c</Property>
      </Properties>
    </LobSystemInstance>
...

In order to use Single Sign-On, please make sure that besides the regular connection information, the following properties are set:

RdbConnection Integrated Security: Tells the Business Data Catalog explicitly to not use integrated security.

SsoApplicationId: Name of the Single Sign-On application as specified in Step 6.5 of the Single Sign-On setup.

SsoProviderImplementation: Default pluggable implementation of the SharePoint SsoProvider.

Besides of the above configuration which is done directly in the application definition file, there are no further actions required to enable Business Data Catalog to connect using Single Sign-On services.

References

[1]: Microsoft MSDN: Business Data Catalog Authentication
[2]: Microsoft TechNet: Configure single sign-on

Posted on SharePoint Blogs

SharePoint's core.css stylesheet: Put it to where it belongs!

mhofer1976 — Sun, 15 Jul 2007 22:25:00 GMT

When rendering CSS stylesheets, SharePoint puts core.css always as the last stylesheet. This post is about how to change this sometimes unwanted behaviour.

OK, why bother with how CSS Stylesheets are rendered? Imagine you create your own Stylesheet overriding a lot of the SharePoint styles defined in core.css (and as you know, there are really "some" styles you might override ). Now, if you follow the SharePoint "standard" approach and add your StyleSheet using the <SharePoint:CssRegistration> webcontrol, you'll always have the problem that the Core.css stylesheet (the one you're actually overriding...) is rendered AFTER your custom stylesheet. Result: All your work is for nothing, since the last one wins when styles will be applied to your web page... So, our friend "core.css" will always be the winner.

There are several approaches how to handle this problem, they are very well documented by Heather Solomon. My approach is somewhat different, though.

I've examined (thanks to .NET Reflector once more), the webcontrols CssRegistration and CssLink. CssRegistration is used to add custom CSS stylesheets using a "standard" approach with WebControls (thus not hardcoding it). CssLink does not accept any input but just renders all registered Stylesheets that are present in the SPContext where the page is rendered. The problem is that most of the methods, properties etc. are only internal and/or private. It is therefore practially impossible to really work with these types in the page declaration - not even in code...

However, there is one nice trick you could do - and in fact it works really well! Let's create a class that inherits from CssLink:

using System;
using System.IO;
using System.Web.UI;
using Microsoft.SharePoint.WebControls;
using Microsoft.SharePoint;

namespace MichaelHofer.SharePoint.PublishingEnhancements
{
    public class EnhancedCssLink : CssLink
    {
        public EnhancedCssLink() : base() { }

Now override the render method and do the "magic": Let the base class render its content, split the rendered "<link>" tags (they are separated by a line-break) and put the last element (= always core.css) on top. But this is not all, you could also do some more stuff. Example? Why not skip rendering of core.css when the current user is an anonymous user who looks at your internet page in "view-only" mode? In these cases, you won't need the core.css most probably... So why not take the overhead away? See this nice blog post for details!

Anyway, back to business, this is the override of the "Render" method:

        protected override void Render(System.Web.UI.HtmlTextWriter output)
        {
            // Let base render the stylesheets
            StringWriter sw = new StringWriter();
            base.Render(new HtmlTextWriter(sw));
            string renderedOutput = originalSw.ToString();

            // Split the styleSheets into an array
            string[] styleSheets = renderedOutput.Split(new char[] { '\n' }, StringSplitOptions.RemoveEmptyEntries);
            if (styleSheets.Length == 0)
            {
                output.Write(renderedOutput);
            }
            else
            {
                string[] reorderedStyleSheets = new string[styleSheets.Length];
                for (int i = 1; i < styleSheets.Length; i++)
                {
                    reorderedStyleSheets = styleSheets[i - 1] + "\n";
                }
                // core.css is always the last stylesheet --> put it in front!
                reorderedStyleSheets[0] = styleSheets[styleSheets.Length - 1] + "\n";
                output.Write(string.Concat(reorderedStyleSheets));
            }
        }
    }
}

That's all! Now compile and deploy (put to GAC and register as safe control, or build a SharePoint solution; see my previous posts for details).

In your master page, declare your assembly. Example:

<%@ Register Tagprefix="PublishingEnhancements" Namespace="MichaelHofer.SharePoint.PublishingEnhancements" Assembly="MichaelHofer.SharePoint.PublishingEnhancements, Version=1.1.0.0, Culture=neutral, PublicKeyToken=7ce575c89ea427a4" %>

And instead of <SharePoint:CssLink> use now your own web control. Example:

<PublishingEnhancements:EnhancedCssLink runat="server"/>

Here you go, all problems with core.css solved, this is what you'll get rendered:

Posted on SharePoint Blogs

Creating custom 404 and landing pages (easy to remember URLs that are redirected) in SharePoint

mhofer1976 — Thu, 12 Jul 2007 13:44:00 GMT

This post is about how to create custom landing pages (www.mysite.com/products or www.mysite.com/newsletter) that directs the visitor through and easy to remember URL to any page in your deep site hierarchy. It also contains the approach how to create custom 404 "Page not found" pages.

In this bost, I'll only explain you the concepts, since I don't really know if I get to code this within a reasonable timeframe. Next week, I'll start at Microsoft, so I'm not sure to have plenty of time for trying things out in the next weeks...

OK, what are we talking about: SharePoint URLs get constructed today a lot better than before. However, it is still not easily possible to create so called "landing pages". These are mostly just entry points that let a visitor easily find its content. Marketing campaigns can print easy to remember URLs on their advertisements etc. Need some examples? OK, here we go:

www.mycompany.com/winthis -- leads to --> www.mycompany.com/marketing/campaigns/summer07/signup.aspx
www.mycompany.com/subscribe -- leads to --> www.mycompany.com/salesandmarketing/ebusiness/newsletters/english/signup.aspx

How should we do this? If you enter such an URL in MOSS you'll get a 404 error. Of course, because this pages do not exists. You couldn't work with Redirect Pages either because they would be located in the "Pages/" section of any site.

Here is now my concept to implement this:

Customize the 404 landing page (I follow Jingmei's post): Create your "custom404.html" page. It must be a HTML page that redirects the requsts, cannot be an ASPX page!
Create a custom "customRedirect.aspx" in the layouts section and implement code:

Lookup a special list in SharePoint "Landing Pages" using the "oldUrl" provided through the QueryString. The list contains a list of Landing Urls ("/newsletter") and the real URL ("www.mycompany.com/salesandmarketing/ebusiness/newsletters/english/signup.aspx") if you find a match, redirect the request to this page (use .NET Reflector how Microsoft does this). If you find no landing page redirect, I would redirect to a hidden publishing page on the root of your site that displays a fully branded 404-message.
Strong name the dll, create a feature and solutioni for deployment etc. For testing, it is enough to put the ASPX in the _layouts folder and the DLL in GAC.

Some thoughts

After reflecting a bit, I think it is only necessary to create one "Landing Pages Redirects" library at the root of your site. URLs tipically should be as short and "human readable" as possible.
With this approach, you have a very robust 404-handling implemented. Do you need additional logic? Just implement it in the already created ASPX-logic.

If I get to it, I'll implement this scenario and create an easy to deploy SharePoint solution out of it. I think this could be interesting to add as a feature to any internet site.

If you are interested in such a WSP solution download as well as the controls described in my posts "Building professional websites using MOSS 2007", basically custom MetaTags and PageTitles, please leave a comment.

Posted on SharePoint Blogs

Building professional internet sites using MOSS 2007 - Page Titles (Part 3)

mhofer1976 — Sun, 08 Jul 2007 12:35:00 GMT

This post is how to build composite page titles using an enhanced FieldValue WebControl.

Page Titles are very important for internet sites since more and more search engines rank pages higher that contain (parts of) the search phrase in the page title. That's why it makes sense to show keywords of your site in your page title - together with the actual location and maybe even the company name. This is what I would call a "composite page title".

Example? See http://www.schleuniger.com/DesktopDefault.aspx/tabid-44/74_read-1590/ from site which I've built some years ago (yes, I know it was not built using MOSS, but the business case is the same).

<title>PowerStrip 9500 BF Automatic wire cutting and stripping machine, cut, strip, wire stripping, coaxial cable stripping, automatic</title>

The title is built using the following pattern: <current location> <product related keywords (same for all products). If you check the other pages you'll find out that not all pages have these composite page titles - it is up to the editor to add them or not, but the <current location> part is of course always present.

I was thinking about how to realize this with MOSS. It is basically a very easy scenario, just add some "FieldValue" web controls in your page layout and that's it. However, I want things to be more "scalable". I want to be able to build composite page titles that do have separators, thus a "suffiix" or a "prefix". I even want to be able to provide a default if one part of the page title pattern does not contain a value (to add some default keywords or whatever). Now this is a little (tiny) bit more complicated.

Creating the control

I've created a new WebControl that inherits from BaseFieldControl:

using System;
using Microsoft.SharePoint.WebControls;
using System.Security.Permissions;
using System.Web;
using System.Web.UI;
using Microsoft.SharePoint.Security;
using System.ComponentModel;

namespace MichaelHofer.SharePoint.PublishingEnhancements
{
    [SharePointPermission(SecurityAction.InheritanceDemand, ObjectModel = true),
    AspNetHostingPermission(SecurityAction.InheritanceDemand, Level = AspNetHostingPermissionLevel.Minimal),
    SharePointPermission(SecurityAction.LinkDemand, ObjectModel = true),
    AspNetHostingPermission(SecurityAction.LinkDemand, Level = AspNetHostingPermissionLevel.Minimal)]
    public class EnhancedFieldValue : BaseFieldControl
    {
        public EnhancedFieldValue()
        {
            base.DisableInputFieldLabel = true;
            base.ControlMode = SPControlMode.Display;
        }

Now I've added the properties I want to be able to configure when I use the control in my page layout or master page:

       protected string m_Prefix = default(string);
        [Bindable(true), Category("Data"), DefaultValue(""), Description("Prefix applied before the field's value.")]
        public string Prefix
        {
            get { return m_Prefix; }
            set { m_Prefix = value; }
        }

        protected string m_Suffix = default(string);
        [Bindable(true), Category("Data"), DefaultValue(""), Description("Suffix applied after field's value.")]
        public string Suffix
        {
            get { return m_Suffix; }
            set { m_Suffix = value; }
        }

        protected string m_Default = default(string);
        //[Bindable(true), Category("Data"), DefaultValue(""), Description("Default applied if field value is empty.")]
        public string Default
        {
            get { return m_Default; }
            set { m_Default = value; }
        }

At last, I implement my own RednerFieldForDisplay-method:

        [SharePointPermission(SecurityAction.Demand, ObjectModel = true)]
        protected override void RenderFieldForDisplay(HtmlTextWriter output)
        {
            string fieldValue = base.Field.GetFieldValueAsHtml(this.ItemFieldValue);
            if (string.IsNullOrEmpty(fieldValue) && !string.IsNullOrEmpty(m_Default))
                fieldValue = m_Default;
            if (!string.IsNullOrEmpty(fieldValue))
                output.Write(string.Format("{0}{1}{2}", m_Prefix, fieldValue, m_Suffix));
        }

If there is no value given for the Field, the default will be applied. If even then there is nothing to write, prefix and suffix are not rendered, otherwise, if present, the value is rendered with the corresponding pre- and/or suffix.

Deyploment:

I won't go into the details of deploment in this post, everything is described in detail in my former post Part 2 (see below)

Creating composite page titles

In your page layout/master page editor (in my case SharePoint Designer), make sure that you have a reference to the assembly containing the EnhancedFieldValue control (see also my last post details). For some reason, SPD doesn't list the control in the "Web Controls (Sharepoint)" section. However, when you start typing the Prefix of the Assembly, it will show you the present controls. Now go ahead and create your composite page title. Example:

<asp:Content ContentPlaceholderID="PlaceHolderPageTitle" runat="server">
<SharePointWebControls:FieldValue id="PageTitle" FieldName="Title" runat="server"/>
<PublishingEnhancements:EnhancedFieldValue runat="server" id="pageTitleExtensions" FieldName="Title_x0020_Extension" Prefix=" - " Suffix=" - Copyright 2007, Michael Hofer" Default="MOSS, WSS, SharePoint, Office" />
</asp:Content>

I'm using a custom field "Title Extension" which an editor can fill within the "Edit Mode Panel" for each field. If the field is blank or for some reason not present, the default is rendered, together with the specified pre- and suffix. The page title is then (no value given) rendered as:

I think that justifies the small development that can be easily deployed using a clean and managable SharePoint Solution!

The next thing I will look at a little bit closer is how to easily (and easy to maintain!) landing pages for a MOSS site. What I mean is:

www.myinternetsite.com/products will redirect to www.myinternetsite.com/products/pages/default.aspx
www.myinternetsite.com/newsletter will redirect to www.myinternetsite.com/signup/default.aspx etc.

Please read also Part 1 & Part 2 of this series who are about building dynamic MetaTags.

Posted on SharePoint Blogs

Building professional internet sites using MOSS 2007 - Metatags (Part 2)

mhofer1976 — Sat, 07 Jul 2007 19:20:00 GMT

(please read the Part 1 here)

In the second part of building a professional set of Metatags for a public-facing MOSS site, I'm going to explain how to use the "MetaTag" WebControl in a MOSS environment.

Deployment

There are two ways how to deploy your assembly, in both cases, you need to Strong-Name it if you want to deploy it to the GAC, which I normally do.

Manual deployment

This is the fastest deplyoment, however only suitable for development, staging or maybe environments with only a single frontend web-server. Still, you should prefer the SharePoint solution deployment. All you have to do here is to:

Put your assembly into the GAC
Add your WebControl(s) to the SaveControl section in the web.config file of all SharePoint webapplications where you want to add enhanced MetaTag support (BTW: did you backup it before doing changes!?):

<SafeControl Assembly="MichaelHofer.SharePoint.PublishingEnhancements, Version=1.0.0.0, Culture=neutral, PublicKeyToken=7ce575c89ea427a4" Namespace="MichaelHofer.SharePoint.PublishingEnhancements" TypeName="*" Safe="True" />

That's it...

SharePoint Solution Deployment

For this deployment method, you create a WSP package that is then added and deployed to SharePoint webapplications using STSADM.exe. This is a pretty common scenario and you'll find plenty of information on how to create and deploy WSP packages so I won't go into details here. Personally, I used the way that I've documented here. Using the PostBuild Commands, the SharePoint Solution containing the WebControl(s) is installed and deployed/installed to my SharePoint web-applications. Nothing more to do at all...

Adding MetaTags to your MOSS site

I use SharePoint designer to implement the MetaTags, but feel free to use any other tool you might prefer. This is what I would suggest to do:

In your MasterPage(s) Header, add

The static metadata
A placeholder that will contain the page-specific metadata
Optionally dynamic metadata using the "MetaTag" WebControl that you fill somehow (with code, other placeholders etc.)
Example:
<head runat="server">
<asp:ContentPlaceHolder runat="server" id="head">
<title><asp:ContentPlaceHolder id="PlaceHolderPageTitle" runat="server" /></title>
</asp:ContentPlaceHolder>



<meta name="author" content="Schleuniger" />
<meta name="Classification" content="Business to Business, B2B, Manufacturing, Industrial Supplies, Machinery and Tools, Machine Tools, Cutting Tools, Wire Strippers" /><meta http-equiv="Content-Language" content="en" />
<meta name="copyright" content="2006, MyCompany" />
<meta name="distribution" content="global" />
<meta name="geo.region" content="CH" />
<meta name="googlebot" content="index, follow" />
<meta name="language" content="English" />
<meta name="rating" content="safe for kids" />
<SharePoint:RobotsMetaTag runat="server"/>
<asp:ContentPlaceHolder runat="server" id="PlaceHolderPageMetaTags"></asp:ContentPlaceHolder>

In you PageLayout-Templates you may go ahead now and fill the "PlaceHolderPageMetaTags" content placeholder with your dynamic metatags.

First of all, notice that the "MetaTag" Controls is listed in the "Server Controls (SharePoint)" list of web controls. Just drag and drop it onto your pagelayout.
Register the control like this, since SPD doesn't seem to do it automatically:

<%@ Register Tagprefix="PublishingEnhancements" Namespace="MichaelHofer.SharePoint.PublishingEnhancements" Assembly="MichaelHofer.SharePoint.PublishingEnhancements, Version=1.0.0.0, Culture=neutral, PublicKeyToken=7ce575c89ea427a4" %>
Example of how your "PlaceHolderPageMetaTags" section could look like:

<asp:Content ContentPlaceHolderID="PlaceHolderPageMetaTags" runat="server">
<PublishingEnhancements:MetaTag runat="server" name="title" id="titleMetaTag"><SharePointWebControls:FieldValue id="titleTag" FieldName="Title" runat="server"/></PublishingEnhancements:MetaTag>
<PublishingEnhancements:MetaTag runat="server" name="description" id="descriptionMetaTag"><SharePointWebControls:FieldValue id="commentsTag" FieldName="Comments" runat="server"/></PublishingEnhancements:MetaTag>
</asp:Content>
Important: Write your metatags all on one line, don't use any linebreaks or whitespaces since these will also be rendered later (well, I guess I could amend this for the future, but for the moment being...)
If not done yet, make sure that you have the corresponding input fields to enter the needed metadata that will be displayed in your MetaTags.

That's it. When you load your page the next time, you will find that all the metatags you've defined are there and filled dynamically!

I think this solution is pretty powerful since it is not limited to fields of a certain content type nor does it have any other restriction. You can fill the metatags by code, by using the available publishing controls Microsoft provides but create also your own etc.

Just for completeness, I provide you herewith also a list of all the metatags that I find you should provide for your site:

Posted on SharePoint Blogs

SharePoint Solution Deployment: Handy Post-Build Events

mhofer1976 — Thu, 05 Jul 2007 22:39:00 GMT

Having built some nice additional SharePoint WebControls, I want them to be deployed as a SharePoint solution, packed into a WSP file - and of course automated. I was very impressed how easy it is, to deploy Workflows based on the MOSS SDK Visual Studio Templates for Workflows. They use an own file structue in the project ("\DeploymentFiles") which consists of the needed .xml & .ddf files and also a .bat file that is used in a post-build command. This .bat is very flexible and does all the magic to deploy the solution and any features contained in it (that is the workflow here).

It is very easy to adopt this to any SharePoint solution. In my case, I just need to deploy a DLL into the GAC and mark it as safe control. However, it is a piece of cake to adopt the files to deploy any kind of feature too. Also, I want to deploy only when I build in "Release" mode, and only if in the post-build command I've set the "DEPLOY" option - since my post-build script performs also an IISRESET which costs a lot of time and resources...

OK, here we go:

Create a sub-folder in the project called "DeploymentFiles".

Add the "manifest.xml" file. This is very simple in my case:

<?xml version="1.0" encoding="utf-8" ?>
<Solution xmlns="http://schemas.microsoft.com/sharepoint/" SolutionId="{91320A34-AC12-4ffa-8076-2ECFBD7BA686}" >
<Assemblies>
    <Assembly DeploymentTarget="GlobalAssemblyCache" Location="MichaelHofer.SharePoint.PublishingEnhancements.dll">
      <SafeControls>
        <SafeControl Assembly="MichaelHofer.SharePoint.PublishingEnhancements, Version=1.0.0.0, Culture=neutral, PublicKeyToken=7ce575c89ea427a4" Namespace="MichaelHofer.SharePoint.PublishingEnhancements" TypeName="*" Safe="True" />
      </SafeControls>
    </Assembly>
</Assemblies>
</Solution>

Add the "wsp_structure.ddf" file:

;This file is for WSP CAB Generation
;A WSS or in this case MOSS solution file is essentially a .cab file,
;use the makecab.exe tool to create the solution package.
;The makecab.exe tool takes a pointer to a .ddf file,
;which describes the structure of the .cab file.
;The format of a .ddf file is basically that
;you declare a standard header and
;then enumerate, one file per line, the set of files by where they live on disk,
;separated by where they should live in the .cab file

.OPTION EXPLICIT ; Generate errors
.Set CabinetNameTemplate="MichaelHofer.SharePoint.PublishingEnhancements.wsp"
.set DiskDirectoryTemplate=CDROM ; All cabinets go in a single directory
.Set CompressionType=MSZIP;** All files are compressed in cabinet files
.Set UniqueFiles="ON"
.Set Cabinet=on
.Set DiskDirectory1="Package"
;All file reference should be from the project root
;Files to place into the CAB Root
..\..\DeploymentFiles\manifest.xml
MichaelHofer.SharePoint.PublishingEnhancements.dll

Add the "PostBuildActions.bat" file. This is a cut-together version of the that is used with workflows:

@ECHO OFF
:: -----------------------------------------------
::
:: --------------------------
:: Post build actions (VS):
:: --------------------------
:: This batch file is run by VS after the user builds the project (F6)
:: It installs a simple solution package to sharepoint. No feature is installed or activated.
:: Adapted by Michael Hofer, originally, this script is used with SharePoint Workflow VS Templates.
:: By default, it skips all deployment steps so that users can build without deploying.
:: Users can use the DEPLOY parameter to install the assembly the GAC and activate
:: stsadm deployment commands.

:: --------------------------
:: How to deploy:
:: --------------------------
::   1. Sign the assembly
:: 2. Use "Release" mode for compilation
::   3. Change "NODEPLOY" to "DEPLOY" in the post build events (in project properties,
::      see "Build Events"->"Post-build event command line")
:: 4. Make sure that the web application urls are set correctly (Ln 88 & 96)
::   5. Press F6 or go to Build->(Re)Build Solution

:: --------------------------
:: Usage:
:: --------------------------
:: - Deployment disabled: call "$(ProjectDir)\DeploymentFiles\PostBuildActions.bat" "$(ConfigurationName)" "$(ProjectDir)" "$(ProjectName)" "$(TargetDir)" "$(TargetName)" NODEPLOY
:: - Deployment enabled: call "$(ProjectDir)\DeploymentFiles\PostBuildActions.bat" "$(ConfigurationName)" "$(ProjectDir)" "$(ProjectName)" "$(TargetDir)" "$(TargetName)" DEPLOY
:: -----------------------------------------------
::

ECHO.
ECHO Running post build actions.
ECHO.

:: e.g."Debug" or "Release"
SET CONFIG=%1
SET CONFIG=%CONFIG:~1,-1%
ECHO CONFIG: %CONFIG%

:: constant placeholder for branch logic comparison; always "DEPLOY"
SET CONFIGVALUE=Release

IF NOT %CONFIG%==%CONFIGVALUE% (ECHO Not in Release mode, skipping deployment & GOTO QUIT)

:: e.g. "C:\Projects\MySolution"
SET PROJECTDIR=%2
SET PROJECTDIR=%PROJECTDIR:~1,-2%
ECHO PROJECTDIR: %PROJECTDIR%

:: e.g. "C:\Projects\MySolution\DeploymentFiles"
SET DEPLOYMENTDIR=%PROJECTDIR%\DeploymentFiles
ECHO DEPLOYMENTDIR: %DEPLOYMENTDIR%

:: e.g. "MySolution"
SET PROJECTNAME=%3
SET PROJECTNAME=%PROJECTNAME:~1,-1%
ECHO PROJECTNAME: %PROJECTNAME%

:: e.g. "C:\Projects\MySolution\bin\Debug"
SET TARGETDIR=%4
SET TARGETDIR=%TARGETDIR:~1,-2%
ECHO TARGETDIR: %TARGETDIR%

:: e.g. "MySolution"(.dll)
SET TARGETNAME=%5
SET TARGETNAME=%TARGETNAME:~1,-1%
ECHO TARGETNAME: %TARGETNAME%

:: cmd parameter, e.g. "DEPLOY" or "NODEPLOY"
SET DEPLOY=%6
ECHO DEPLOY: %DEPLOY%

:: constant placeholder for branch logic comparison; always "DEPLOY"
SET DEPLOYVALUE=DEPLOY
ECHO DEPLOYVALUE: %DEPLOYVALUE%

IF NOT %DEPLOY%==%DEPLOYVALUE% (ECHO Skipping deployment & GOTO QUIT)

IF EXIST "%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\BIN\STSADM.EXE" (SET STSADM="%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\BIN\STSADM.EXE") ELSE (ECHO STSAMD.EXE could not be found! & GOTO QUIT)

ECHO.
ECHO Generating %PROJECTNAME%.wsp ...
ECHO.

makecab /f "%DEPLOYMENTDIR%\wsp_structure.ddf"

ECHO.
ECHO Retracting and deleting solution (if it exists)...
ECHO.

%STSADM% -o retractsolution -name %PROJECTNAME%.wsp -url http://localhost:8081 -local
%STSADM% -o deletesolution -name %PROJECTNAME%.wsp

ECHO.
ECHO Adding and deploying the solution...
ECHO.

%STSADM% -o addsolution -filename "Package\%PROJECTNAME%.wsp"
%STSADM% -o deploysolution -name %PROJECTNAME%.wsp -url http://localhost:8081 -local -allowGacDeployment -force

GOTO FINISH

:: -----------------------------------------------
::
:FINISH
::

ECHO Doing an iisreset...
ECHO.

CALL iisreset

:: -----------------------------------------------

:: -----------------------------------------------
::
:QUIT

ECHO.
ECHO Done
ECHO.

::
:: -----------------------------------------------

Add the post-build event command (use NODEPLOY and the script doesn't execute):

call "$(ProjectDir)\DeploymentFiles\PostBuildActions.bat" "$(ConfigurationName)" "$(ProjectDir)" "$(ProjectName)" "$(TargetDir)" "$(TargetName)" DEPLOY

Switching now to "Release" build mode and press F6, the project is compiled, the WSP is generated and the solution is installed automatically. Handy, right!?

Posted on SharePoint Blogs