Step by step process for changing master page automatically using STSADM command line tool

Recently, my colleague (Ankul Mathur) and me (much of the work done by him!) created a custom solution to change the SharePoint master page automatically on day to day basis.

Requirement: Change the master page based on the day of the week. Example; Monday should have Yellow master page and similarly each day will have its own master page. In a nutshell, the client wants a different looking very day. I know this is usability failure but can’t help!The requirement seems bit weird as we could have done this using CSS alone, but the master page components differ from one master page to the other.  

Ok enough of bantering, lets dive deep into process;

Step 1: Download Gary Lapointe’s Custom Stsadm Command Line tool WSP file for MOSS or WSS from http://stsadm.blogspot.com/2009/02/downloads.html .

Step 2: Follow the steps giving in the article to install and activate the wsp service on the server using Stsadm command line tool.

Step 3: On the server under bin folder in 12 hive run the Stsadm command for setmasterpage to check the Stsadm for setmasterpage is working correctly.

Step 4: Create a Project in VS 2005/2008 named it CustomSTSADM and added a reference for commandlineprocess after download a file from http://www.codeguru.com/csharp/csharp/cs_misc/userinterface/article.php/c8503 . Here is the code;

Project.cs

   1: using System;

   2: using System.Collections.Generic;

   3: using System.Linq;

   4: using System.Text;

   5: using twComps;

   6: 

   7: namespace CustomSTSADM

   8: {

   9:     class Program

  10:     {

  11:         static void Main(string[] args)

  12:         {

  13:             DateTime dt = DateTime.Now;

  14:             string masterPage = string.Empty;

  15: 

  16:             switch (dt.DayOfWeek.ToString().ToLower())

  17:             {

  18:                 case "monday":

  19:                     masterPage = System.Configuration.ConfigurationSettings.AppSettings["masterPageMon"];

  20:                     break;

  21:                 case "tuesday":

  22:                     masterPage = System.Configuration.ConfigurationSettings.AppSettings["masterPageTue"];

  23:                     break;

  24:                 case "wednesday":

  25:                     masterPage = System.Configuration.ConfigurationSettings.AppSettings["masterPageWed"];

  26:                     break;

  27:                 case "thursday":

  28:                     masterPage = System.Configuration.ConfigurationSettings.AppSettings["masterPageThu"];

  29:                     break;

  30:                 default:

  31:                     masterPage = System.Configuration.ConfigurationSettings.AppSettings["masterPageDef"];

  32:                     break;

  33:             }

  34: 

  35:             string masterPageLink = System.Configuration.ConfigurationSettings.AppSettings["masterPageLink"];

  36: 

  37:             CommandLineProcess cmd = new CommandLineProcess();

  38:             cmd.Command = "stsadm";

  39:             cmd.Arguments = string.Format(" -o gl-setmasterpage -url \"{0}\" -sitemaster \"{1}{2}.master\" -systemmaster \"{3}{4}.master\"",

  40:                 System.Configuration.ConfigurationSettings.AppSettings["portalLink"],

  41:                 masterPageLink, masterPage, masterPageLink, masterPage);

  42: 

  43:             bool bSuccess = cmd.Start();

  44:         }

  45:     }

  46: }

App.Config

   1: <?xml version="1.0" encoding="utf-8" ?>

   2: <configuration>

   3:   <appSettings>

   4:     <add key="masterPageMon" value="blue" />

   5:     <add key="masterPageTue" value="green" />

   6:     <add key="masterPageWed" value="yellow" />

   7:     <add key="masterPageThu" value="grey" />

   8:     <add key="masterPageDef" value="pink" />

   9: 

  10:     <add key="masterPageLink" value="/_catalogs/masterpage/"/>

  11:     <add key="portalLink" value="http://server name" />

  12:

  13:   </appSettings>

  14: </configuration>

Step 5: Build the Project. This will create a folder with the project name inside that there will be a Bin folderàRelease folder à CustomSTSADm.exe, CommandLineProcess.dll, and CustomSTSADM.exe.config file.

Step 6: Copy all the above 3 files to bin folder under 12 hive on the server.

Step7: Run the .exe file on Windows Server 2003 and the master page is automatically set to the site set in the .exe.config file. And for Windows server 2008 right click on the .exe file and click on “Run as Administrator” it will set the new master page.

Step 8: Schedule the .exe file in Windows Scheduler to be run on daily/weekly/monthly basis.

On Windows 2008 Server;

Go to Start –> Programs –> Accessories –> System Tools –> Task Scheduler and set the following setting as shown in the images below:  

As always, if you happen to know a much better way to accomplish this, please feel free to share.

Rampup Modules for SharePoint Development

Previously I posted about learning SharePoint development for Jr SharePoint developers. To further add to that, Microsoft just released new module for SharePoint development in their rampup incentive.

For those of you who don’t know Ramup.

Ramp Up is a free, online, community-based learning program, with a number of different tracks that will help you build your portfolio of professional development skills. Ramp Up has a solid foundation of premium technical content from subject-matter gurus, and provides easy-to-access content in a variety of forms that guide you in learning the important skills. Join Ramp Up (it’s free!) and help advance your career

So why are still reading this! Go to Ramp up site and sharpen your skills.

Ramp Up SharePoint Modules.

Part 1

Part 2

All the best!

Points to remember when building custom SharePoint Solutions

It is very important to remember the below points when you build custom SharePoint Solutions.

Manageability   If you have to back up and restore the complete environment (such as in a disaster recovery scenario or if you are moving hardware), you must have backups for all custom elements (such as a custom Web Part that was developed for the environment or a custom site definition) and remember to add them back to the environment again when you restore. This is because you cannot restore the configuration database, which contains all of the references to these custom elements. Therefore, you must add them back in to the restored environment. For example, you have to add back the custom site definitions and install the custom Web Parts. If you forget a custom element when you move to a new server or restore a server, you can cause errors in users’ team sites and you will have to track down the code that you need while users wait.

Supportability   Having custom elements in the environment can add to troubleshooting time when something goes wrong. Each custom piece of code is unique, and can be either complex or simple, and can consume additional memory to run. Consider the number of places the custom code is used and what its effect is on the system. Also, consider how you can exclude the customizations as part of the cause of a problem when troubleshooting. If you are creating the custom code, be sure to design it so that any errors from the customizations are logged in both the event log — for Microsoft Operations Manager (MOM) events — and any other location that the organization uses for troubleshooting so that you can troubleshoot the errors.

Usability   Consider the usability of solutions, Web Parts, and templates. If you have so many custom templates for team sites in the environment that the list of templates or Web Parts scrolls for multiple screens (for example, 50 is too many to read and differentiate), consider whether you must have all those custom elements, whether you can break the list up in some way, or whether you should roll them up into common feature packs for easier browsing and tracking.

Source: Plan for custom elements

SharePoint Development Best Practices – Checklist

Today, I came across a checklist for SharePoint Custom Solution Code Acceptance. I reckon this checklist (modified if necessary) should be part of your test plans if your SharePoint Project needs custom solution bits. Code acceptance checklist outlines best practices for security, session management, validation, sensitive data, exception handling, Web parts, documentation, general software development. I think it is very important for any SharePoint developer to keep these best practices in mind. Of all the best practices I feel every SharePoint developer (novice to experienced) should at least follow ‘Web part development’ and ‘general software development’ best practices as a mantra!!

Best Practices for SharePoint Web part Development:

1. Custom Web parts (including resource files) are contained within a SharePoint Feature and are packaged as a SharePoint solution in order to be deployed.
2. The configuration of Web parts that are being deployed gives the administrator the flexibility of deploying to the Web application level or lower.
3. You use the SharePoint Web part infrastructure’s standardized set of connection interfaces for Web parts to exchange information with each other at run time.
4. Source code for third party Web parts solutions, whenever possible, is provided with adequate documentation to ensure good technical support.
5. All custom Web parts utilize the SharePoint architecture to ensure consistent behaviour across the application for functionality such as single sign-on, feature deployment, and so on.

Best Practices for General SharePoint Software Development:

1. Assemblies have a strong name. (Dynamically generated ASP.NET Web page assemblies cannot currently have a strong name.)
2. You use delay signing as a way to protect and restrict the private key that is used in the strong name and signing process.
3. Assemblies include declarative security attributes (with SecurityAction.RequestMinimum) to specify minimum permission requirements.
4. Highly privileged assemblies are separated from lower privileged assemblies.
5. If an assembly is to be used in a partial-trust environment (for example, it is called from a partial-trust Web application), then privileged code is in a separate assembly.
6. You rely on a native configuration file to support the application instead of changing the configuration to the Web.config.
7. You use .NET Framework 2.0, 3.0, or 3.5.
8. You use a single .NET Framework version. You do not mix multiple versions.
9. Your code is 64 bit compatible.
10. Your application does not try to directly access any SharePoint databases. Data stores in SharePoint databases are only updated by using the SharePoint object model.
11. You avoid hard coding strings and labels. You use resources or language files instead.
12. When referencing the SPWeb or SPSite objects, you employ a using statement or, alternatively, you use an explicit call of the .Dispose method to ensure proper use and disposing of the memory objects.
13. You use caching as appropriate to reduce unnecessary round trips. For Web parts, you expose the cache expiration (duration) as a Web part property.
14. When packaging your solution, you include a Code Access Security policy for the solution and, if necessary, include your assembly in the Safe Controls list though the solution.
15. When logging code, you use the Portal Log class to log the SharePoint Unified Logging Service (ULS) logs.
16. If you need to update multiple list items by using remote code, you use the Web service to update list items. You only use SPListItem.Update() if you have to update more than one item at a time by using local OM-based code.
17. When using the Count property of a SPListItemCollection, you only call it once and then store it in a variable that you can refer to when looping. You do not call it inside a loop.
18. The solution uses the AppSettings object to implement XML mapping. (This can be provided by using the settings persistence framework in .NET 2.0, 3.0, or 3.5.) The solution avoids creating custom XML files and a strongly typed object for XML mapping.
19. Installation and deployment logging are provided in the event logs to enable appropriate operational troubleshooting during installation and uninstallation.

Please note that, the best practices are not limited to ones mentioned above. Best Practices are something which evolve with experience. If you know of any other best practices which you think are worth sharing don’t hesitate to share them in comments.

For other best practices please refer to Sample code acceptance checklist for IT organizations.

For a printable version of the sample code checklist that you can edit, download the list as a Word 2007 document (.doc).

Sample code acceptance checklist for IT organizations (http://go.microsoft.com/fwlink/?LinkId=125134)

Additional Resources for Best Practice SharePoint Development

• Microsoft Office SharePoint Server 2007 SDK (http://go.microsoft.com/fwlink/?LinkID=72208)

• Windows SharePoint Services 3.0 SDK (http://go.microsoft.com/fwlink/?LinkID=113927)

• Development Tools and Techniques for Working with Code in Windows SharePoint Services 3.0 (http://go.microsoft.com/fwlink/?LinkId=123413)

• Working with ASP.Net 2.0 Web parts and WSS 3.0 (http://go.microsoft.com/fwlink/?LinkId=123429)

• Best Practices: Common Coding Issues When Using the SharePoint Object Model (http://go.microsoft.com/fwlink/?LinkId=123414)

• Windows SharePoint Services Developer Center (http://go.microsoft.com/fwlink/?LinkId=123428)

• MSDN Webcast: Essentials of Application Security (Part 1 of 3): Secure Communications (Level 200) (http://go.microsoft.com/fwlink/?LinkId=123430)

• SharePoint Server 2007 Developer Portal (http://go.microsoft.com/fwlink/?LinkID=119449)

• Microsoft Anti-Cross Site Scripting Library V1.5 (http://go.microsoft.com/fwlink/?LinkId=123431)

• Improving Web Application Security: Threats and Countermeasures (http://go.microsoft.com/fwlink/?LinkId=123432)

• Exception Management Architecture Guide (http://go.microsoft.com/fwlink/?LinkId=123433)

• SharePoint Products and Technologies White Paper: Implementing Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0 Solutions (http://go.microsoft.com/fwlink/?LinkId=114834)

• How to programmatically test for canonicalization issues with ASP.NET (http://go.microsoft.com/fwlink/?LinkId=123434)

• Validating ASP.NET server controls (http://go.microsoft.com/fwlink/?LinkId=123435)

• MSDN Webcast: Digging into Server-Side State Management (http://go.microsoft.com/fwlink/?LinkId=123436)

• SharePoint Products and Technologies customization policy (http://go.microsoft.com/fwlink/?linkid=92311)

Web Development Helper plugs into Internet Explorer and provides tools for Ajax and Web development

If you haven’t seen this before…

Web Development Helper is a free browser extension for Internet Explorer that provides a set of tools and utilities for the Web developer, esp. Ajax and ASP.NET developers. The tool provides features such as a DOM inspector, an HTTP tracing tool, and script diagnostics and immediate window.

Web Development Helper works against IE6+, and requires the .NET Framework 2.0 or greater to be installed on the machine.

Once installed, the tool can be activated using the Tools | Web Development Helper command. You can also customize your browser’s toolbar to add a button for this command to facilitate frequent use. Clicking on the menu command or browser button brings up the tool’s console window and set of commands.

Page Features:

· DOM inspector allows viewing all elements, selected elements, or elements matching an ID or CSS class, their attributes and styles.

· Capturing a screen shot of the current page.

· Viewing page information such as metadata, tags, and linked resources.

Networking Features:

· Logging HTTP (and HTTPS) requests initiated by the browser or Ajax scripts

· Viewing request and response details.

· Ability to filter the types of URLs to log.

Scripting Features:

· Trap script errors to see detailed (and correct) call stack for the script error.

· A script console to provide trace functionality to scripts using the window.debugService script API.

· An immediate window to write and run script.

· A script class browser to browse classes defined in script (specifically classes written to the ASP.NET Ajax or Script# pattern).

ASP.NET Features:

· View view state in the page in raw, decoded, and parsed forms, to understand what is being generated into the view state (esp. useful for control developers).

· View items stored by applications into cache, and the ability to remove them for purposes of testing.

· View trace information, and hide it from the page, so it does not get in the way of your page layout.

http://www.codeplex.com/webdevhelper/Release/ProjectReleases.aspx?ReleaseId=11062

Note: Cross posted from an email sent by my colleague Paul Turner.

Resources for Junior SharePoint Developers

We all know that, SharePoint is rapidly becoming a most liked and wanted collaboration PLATFORM for enterprises across the world and many developers from different platforms are eyeing on become a SharePoint developer. Especially, I can see a huge demand for SharePoint Developers here in Australia. So guys its time to pull your socks and learn SharePoint.

Paul Andrew from Microsoft has put together a great list of resources and guidelines (I should say!) for entry level SharePoint developers. If you really want to become a SharePoint developer and standout in the crowd, please checkout http://blogs.msdn.com/pandrew/archive/2008/05/01/getting-started-with-sharepoint-development.aspx 

Following the list should make your life lot easier!!  

Forthcoming Introductory SharePoint Development Web Casts

Microsoft is putting a series of Introductory SharePoint development web casts by SharePoint Community Leaders!

Please find the schedule @

http://blogs.msdn.com/pandrew/archive/2008/05/12/sharepoint-developer-msdn-web-cast-series.aspx