Continuing the discussion about how developing projects in a WSS v3 or MOSS world is different to traditional .NET development, in this post I am going to discuss the mechanics of controlling quality and consistency within your projects.

The central issue that causes a fair amount of trouble to large established teams is the lack of support of Team Foundation Server within Sharepoint Designer.

Project Management / Team Leader interaction with developers

Those development houses who have embraced the Team Foundation Server model are hopefully seeing their teams benefit from better communication due to the tight integration of issue logs, bug lists, tasks and project plans with the tools that their staff use in their every day life. In the case of your developers, this is Visual Studio. Project Managers and Team Leaders can be updated of progress because developers are getting their tasks from within Visual Studio.

Sharepoint Designer doesn't have this integration with TFS, so the dissemination of information around the team will be less effective.

Source Control and Automatic Builds

Another feature of TFS is that it comes with an enterprise level source control system. Even if you aren't using TFS, larger dev houses will have moved away from the (buggy) VSS product, and will be using something like SourceGear's Vault. Similarly, you will probably be automating your builds, using MSBuild or CruiseControl. 

With these systems come developer guidelines and processes, a lot of which will have to change under MOSS. Since the front end code – the master pages, the page layouts, not to mention the image files, the CSS and the XSLT code – is all stored in the database, this will mean that your existing processes for automated builds and managing source control will have to be changed accordingly.

Code Quality Assurance

This is one area that I think is better in SPD than in Visual Studio. Since you will be writing almost no c# code within your SPD environment, you don't have to worry too much about your FxCop (or MSBuild) rules. SPD comes with three validation tools which will give you better front end code – improvements to the checks for Accessibility, (X)HTML and CSS. Used well, these tools will give your website builders much better code.

Continuing the discussion about how developing projects in a WSS v3 or MOSS world is different to traditional .NET development, in this post I am going to discuss the mechanics of controlling quality and consistency within your projects.

The central issue that causes a fair amount of trouble to large established teams is the lack of support of Team Foundation Server within Sharepoint Designer.

Project Management / Team Leader interaction with developers

Those development houses who have embraced the Team Foundation Server model are hopefully seeing their teams benefit from better communication due to the tight integration of issue logs, bug lists, tasks and project plans with the tools that their staff use in their every day life. In the case of your developers, this is Visual Studio. Project Managers and Team Leaders can be updated of progress because developers are getting their tasks from within Visual Studio.

Sharepoint Designer doesn't have this integration with TFS, so the dissemination of information around the team will be less effective.

Source Control and Automatic Builds

Another feature of TFS is that it comes with an enterprise level source control system. Even if you aren't using TFS, larger dev houses will have moved away from the (buggy) VSS product, and will be using something like SourceGear's Vault. Similarly, you will probably be automating your builds, using MSBuild or CruiseControl. 

With these systems come developer guidelines and processes, a lot of which will have to change under MOSS. Since the front end code – the master pages, the page layouts, not to mention the image files, the CSS and the XSLT code – is all stored in the database, this will mean that your existing processes for automated builds and managing source control will have to be changed accordingly.

Code Quality Assurance

This is one area that I think is better in SPD than in Visual Studio. Since you will be writing almost no c# code within your SPD environment, you don't have to worry too much about your FxCop (or MSBuild) rules. SPD comes with three validation tools which will give you better front end code – improvements to the checks for Accessibility, (X)HTML and CSS. Used well, these tools will give your website builders much better code.

WSS v3 / MOSS moves us to a brave new world of software development. In my opinion it is a major shift for large and medium sized dev houses. This series of posts examine some of the challenges likely to be felt by these companies.

1. Who do you need on a v3 project?

In the past, Sharepoint development was fairly low level; it was just too hard to make significant changes to the interface, and while there was some demand for .NET code when building custom web parts, for the main you could get away with just rolling out a standard build and customizing it using menus. In contrast, MCMS (and other WCM products) gave you complete flexibility of design, but demanded skilled .NET developers to put all the pieces together. MCMS was more of a toolset than a formal product.

This has changed in the new versions, to the extent that Sharepoint provides a wealth of functionality and self-service site creation to the end user, but is as flexible as MCMS in terms of user interface.

The MOSS / WSSv3 paradigm is that you place all of your business logic and code in web controls (traditional ASP.NET server controls, user controls or web parts). The page itself should not require any code directly within it; your page and master page should be used for layout only. This has changed the nature of the developer.

You will still need your standard set of people, some or all of the following:

ú         Network Administration

ú         Configuration Manager

ú         Quality Assurance team

ú         Project Manager

ú         Technical Lead / Architect

ú         Information Architect

ú         Graphical Designer

The key issue here is that there are now two distinct types of developer:

1) Component Developers: This role is for those developers who will use C# / VB.NET to build controls and web parts which can be reused in any solution. They will still work in VS.

2) Web Site Builders (aka Designers): This role makes use of out of the box controls and webparts, together with any custom controls, and uses (X)HTML, CSS and XSLT to brand a site. They use SP Designer, they don't need to make use of VS at all.

This is going to mean a bit of reorganisation in your teams, and change the way you resource projects. It also means that your component developers should be able to spend more time on sourcing and building reusable components rather than churning out websites. This should mean that over time you should see reduced build times and costs, which will benefit you and your clients.

For a big dev house, this poses several other issues, such as how you set up your development environments for large development teams, how you deal with version control and code quality, all which I'll come onto in later posts.

WSS v3 / MOSS moves us to a brave new world of software development. In my opinion it is a major shift for large and medium sized dev houses. This series of posts examine some of the challenges likely to be felt by these companies.

1. Who do you need on a v3 project?

In the past, Sharepoint development was fairly low level; it was just too hard to make significant changes to the interface, and while there was some demand for .NET code when building custom web parts, for the main you could get away with just rolling out a standard build and customizing it using menus. In contrast, MCMS (and other WCM products) gave you complete flexibility of design, but demanded skilled .NET developers to put all the pieces together. MCMS was more of a toolset than a formal product.

This has changed in the new versions, to the extent that Sharepoint provides a wealth of functionality and self-service site creation to the end user, but is as flexible as MCMS in terms of user interface.

The MOSS / WSSv3 paradigm is that you place all of your business logic and code in web controls (traditional ASP.NET server controls, user controls or web parts). The page itself should not require any code directly within it; your page and master page should be used for layout only. This has changed the nature of the developer.

You will still need your standard set of people, some or all of the following:

ú         Network Administration

ú         Configuration Manager

ú         Quality Assurance team

ú         Project Manager

ú         Technical Lead / Architect

ú         Information Architect

ú         Graphical Designer

The key issue here is that there are now two distinct types of developer:

1) Component Developers: This role is for those developers who will use C# / VB.NET to build controls and web parts which can be reused in any solution. They will still work in VS.

2) Web Site Builders (aka Designers): This role makes use of out of the box controls and webparts, together with any custom controls, and uses (X)HTML, CSS and XSLT to brand a site. They use SP Designer, they don't need to make use of VS at all.

This is going to mean a bit of reorganisation in your teams, and change the way you resource projects. It also means that your component developers should be able to spend more time on sourcing and building reusable components rather than churning out websites. This should mean that over time you should see reduced build times and costs, which will benefit you and your clients.

For a big dev house, this poses several other issues, such as how you set up your development environments for large development teams, how you deal with version control and code quality, all which I'll come onto in later posts.

This has come up in a number of newsgroups, beta and public, and I've found a solution to this. The basic problem is that SP Designer expects to be authenticating using Windows Auth, and this means that you get access denied errors when connecting to a Forms Authentication site. There are two ways around this.

The first way is to authenticate via IE first, making sure that you save your credentials. SP Designer should be able to use that authentication cookie to authenticate against SP.

The slightly nicer way is to extend your web application onto a secondary IIS website; in doing so it allows you to have one content database but multiple authentication providers. This will allow you to bind to the Windows Auth version of the system using your AD account, and the Forms Authentication version using whatever provider you have specified. In a public facing production environment this can be very useful. Clearly you may want your public facing users to have limited rights over your website content, and by using IP restrictions and not publishing the second (Windows Auth) version of the web application to the outside world you should improve your overall security.

See Configuring Multiple Authentication Providers for SharePoint 2007 for details about how to do this.

PS: Yes, I know. I've been slack. As various people told me at last week's UK Sharepoint User Group. I just haven't got into the habit of writing regular blog posts. And I've been quite busy on some interesting new projects. That's my excuse and I'm sticking to it.

So hopefully this won't be another false dawn. We'll see…

This has come up in a number of newsgroups, beta and public, and I've found a solution to this. The basic problem is that SP Designer expects to be authenticating using Windows Auth, and this means that you get access denied errors when connecting to a Forms Authentication site. There are two ways around this.

The first way is to authenticate via IE first, making sure that you save your credentials. SP Designer should be able to use that authentication cookie to authenticate against SP.

The slightly nicer way is to extend your web application onto a secondary IIS website; in doing so it allows you to have one content database but multiple authentication providers. This will allow you to bind to the Windows Auth version of the system using your AD account, and the Forms Authentication version using whatever provider you have specified. In a public facing production environment this can be very useful. Clearly you may want your public facing users to have limited rights over your website content, and by using IP restrictions and not publishing the second (Windows Auth) version of the web application to the outside world you should improve your overall security.

See Configuring Multiple Authentication Providers for SharePoint 2007 for details about how to do this.

PS: Yes, I know. I've been slack. As various people told me at last week's UK Sharepoint User Group. I just haven't got into the habit of writing regular blog posts. And I've been quite busy on some interesting new projects. That's my excuse and I'm sticking to it.

So hopefully this won't be another false dawn. We'll see…

Lawrence Liu (Community Lead, Sharepoint Products and Technologies) asked me to write a guest blog entry for the ECM Team blog [http://blogs.msdn.com/ecm]. The introduction is below, the main body is here.

In the past, most SharePoint developers would have run a mile when faced with an initial design brief like this:

While it had been difficult in the past to brand a SharePoint-based website with the kind of flexibility that marketing departments demand for their publicly facing websites, SharePoint developers can stop running right about now. This limitation simply disappears in the 2007 version of SharePoint with the support for ASP.NET 2.0 Master Pages technology.

So, how did we go about creating a site with SharePoint that looks nothing like a typical SharePoint site? Surprisingly, it didn't involve lots of C# code or editing files we really weren't supposed to be. We actually made use of a lot of out of the box controls, and in the main used XHTML, CSS and XSLT to achieve the output that our client required.

To read the full article – go to the ECM Team Blog: http://blogs.msdn.com/ecm/archive/2006/09/30/777819.aspx

Lawrence Liu (Community Lead, Sharepoint Products and Technologies) asked me to write a guest blog entry for the ECM Team blog [http://blogs.msdn.com/ecm]. The introduction is below, the main body is here.

In the past, most SharePoint developers would have run a mile when faced with an initial design brief like this:

While it had been difficult in the past to brand a SharePoint-based website with the kind of flexibility that marketing departments demand for their publicly facing websites, SharePoint developers can stop running right about now. This limitation simply disappears in the 2007 version of SharePoint with the support for ASP.NET 2.0 Master Pages technology.

So, how did we go about creating a site with SharePoint that looks nothing like a typical SharePoint site? Surprisingly, it didn't involve lots of C# code or editing files we really weren't supposed to be. We actually made use of a lot of out of the box controls, and in the main used XHTML, CSS and XSLT to achieve the output that our client required.

To read the full article – go to the ECM Team Blog: http://blogs.msdn.com/ecm/archive/2006/09/30/777819.aspx

When customising master pages, or starting from scratch, it is useful to know what the out of the box pages require in terms of Content Placeholders. If you get this wrong, you will get an error like this:  

Server Error in '/' Application.

---

Cannot find ContentPlaceHolder 'PlaceHolderPageTitle' in the master page '/_catalogs/masterpage/Custom.master', verify content control's ContentPlaceHolderID attribute in the content page.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Web.HttpException: Cannot find ContentPlaceHolder 'PlaceHolderPageTitle' in the master page '/_catalogs/masterpage/Custom.master', verify content control's ContentPlaceHolderID attribute in the content page.

The reason for this error is, as it says, a missing content placeholder definition in your master page. Because it is quite frustrating to go through these one by one, here is a definitive list of all of the out of the box content placeholders:

Site Master Pages [used in TopNavFlyouts.master, for example]

• PlaceHolderPageTitle
• PlaceHolderAdditionalPageHead
• PlaceHolderLogin
• PlaceHolderSearchArea
• PlaceHolderTitleBreadcrumb
• PlaceHolderLeftNavBar
• PlaceHolderPageTitleInTitleArea
• PlaceHolderMain
• PlaceHolderPageImage
• PlaceHolderBodyLeftBorder
• PlaceHolderNavSpacer
• PlaceHolderTitleLeftBorder
• PlaceHolderTitleAreaSeparator
• OSSConsole
• PlaceHolderMiniConsole
• PlaceHolderCalendarNavigator
• PlaceHolderLeftActions
• PlaceHolderPageDescription
• PlaceHolderBodyAreaClass
• PlaceHolderTitleAreaClass

System Master Page [used in default.master, for example]

• PlaceHolderPageTitle
• PlaceHolderAdditionalPageHead
• PlaceHolderSiteName
• PlaceHolderSearchArea
• PlaceHolderTopNavBar
• WSSDesignConsole
• SPNavigation
• PlaceHolderTitleLeftBorder
• PlaceHolderTitleBreadcrumb
• PlaceHolderPageTitleInTitleArea
• PlaceHolderMiniConsole
• PlaceHolderTitleRightMargin
• PlaceHolderTitleAreaSeparator
• PlaceHolderLeftNavBarDataSource
• PlaceHolderCalendarNavigator
• PlaceHolderLeftNavBarTop
• PlaceHolderLeftNavBar
• PlaceHolderLeftActions
• PlaceHolderNavSpacer
• PlaceHolderLeftNavBarBorder
• PlaceHolderBodyLeftBorder
• PlaceHolderPageDescription
• PlaceHolderMain
• PlaceHolderBodyRightMargin
• PlaceHolderFormDigest
• PlaceHolderUtilityContent
• PlaceHolderBodyAreaClass
• PlaceHolderTitleAreaClass

When customising master pages, or starting from scratch, it is useful to know what the out of the box pages require in terms of Content Placeholders. If you get this wrong, you will get an error like this:  

Server Error in '/' Application.

---

Cannot find ContentPlaceHolder 'PlaceHolderPageTitle' in the master page '/_catalogs/masterpage/Custom.master', verify content control's ContentPlaceHolderID attribute in the content page.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Web.HttpException: Cannot find ContentPlaceHolder 'PlaceHolderPageTitle' in the master page '/_catalogs/masterpage/Custom.master', verify content control's ContentPlaceHolderID attribute in the content page.

The reason for this error is, as it says, a missing content placeholder definition in your master page. Because it is quite frustrating to go through these one by one, here is a definitive list of all of the out of the box content placeholders:

Site Master Pages [used in TopNavFlyouts.master, for example]

• PlaceHolderPageTitle
• PlaceHolderAdditionalPageHead
• PlaceHolderLogin
• PlaceHolderSearchArea
• PlaceHolderTitleBreadcrumb
• PlaceHolderLeftNavBar
• PlaceHolderPageTitleInTitleArea
• PlaceHolderMain
• PlaceHolderPageImage
• PlaceHolderBodyLeftBorder
• PlaceHolderNavSpacer
• PlaceHolderTitleLeftBorder
• PlaceHolderTitleAreaSeparator
• OSSConsole
• PlaceHolderMiniConsole
• PlaceHolderCalendarNavigator
• PlaceHolderLeftActions
• PlaceHolderPageDescription
• PlaceHolderBodyAreaClass
• PlaceHolderTitleAreaClass

System Master Page [used in default.master, for example]

• PlaceHolderPageTitle
• PlaceHolderAdditionalPageHead
• PlaceHolderSiteName
• PlaceHolderSearchArea
• PlaceHolderTopNavBar
• WSSDesignConsole
• SPNavigation
• PlaceHolderTitleLeftBorder
• PlaceHolderTitleBreadcrumb
• PlaceHolderPageTitleInTitleArea
• PlaceHolderMiniConsole
• PlaceHolderTitleRightMargin
• PlaceHolderTitleAreaSeparator
• PlaceHolderLeftNavBarDataSource
• PlaceHolderCalendarNavigator
• PlaceHolderLeftNavBarTop
• PlaceHolderLeftNavBar
• PlaceHolderLeftActions
• PlaceHolderNavSpacer
• PlaceHolderLeftNavBarBorder
• PlaceHolderBodyLeftBorder
• PlaceHolderPageDescription
• PlaceHolderMain
• PlaceHolderBodyRightMargin
• PlaceHolderFormDigest
• PlaceHolderUtilityContent
• PlaceHolderBodyAreaClass
• PlaceHolderTitleAreaClass