Rendering Different Colors for each row in an ASP.NET Gridview

This is simple as handling the MyGridViewName_RowDataBound event. The following code sample is used in the following scenario:

1. The grid is bound to a LINQDataSource (the e.Row.DataItem has a type of "DynamicClass" and so cannot be cast directly)
2. Consequently uses reflection to get a nested property inside the e.Row.DataItem, then casts that to a known LINQ2SQL class.
3. From this reflected information, grabs the display colour HEX value (e.g. #CCFFCC and converts it to a System.Drawing.Color colour (by using System.Drawing.ColorTranslator).

        protected void proposalListGridView_RowDataBound(object sender, GridViewRowEventArgs e)
        {
            if (e.Row.RowType == DataControlRowType.DataRow)
            {
                DoPBusiness.PlanningProposalTracking.PP_LIST_Status status = 
                    (DoPBusiness.PlanningProposalTracking.PP_LIST_Status)
                    e.Row.DataItem.GetType()
                    .GetProperty("PP_LIST_Status")
                    .GetValue(e.Row.DataItem, null);

                e.Row.BackColor = System.Drawing.ColorTranslator.FromHtml(status.DisplayColour); 
            }
        }

NB. An alternative (and preferred) to using relection to get the nested property is using LINQ projection - which is how I did it when I checked the code into source. control. However, the code sample above still illustrates the topic of this post.

SharePoint 2007 - Backup and Restore via stsadm.exe and a Warning About Using the -o setsitelock Flag

For a presentation to a client the other day, I used my "swiss army knife" VMWare image with SharePoint 2007 on it. However, I quickly needed to move a site collection from my MOSS instance to a new machine. There are several options to do this, including:

• Doing a SQL DB backup
  
• Using SharePoint Designer 2007 (which I occasionally use as it offers the most granular backup and restore options.
• Using stsadm restore functionality.
  

For backups of less than 15GB, stsadm is the simplest option. However, the simplest option isn't without its complications, even (or especially) if you follow the MSDN recommended steps:

1. As per the link below, the site should be made read only otherwise the backup may be corrupted (due to partial or incomplete writes to the content databases) . I normally just do a backup with stsadm without locking it first and it has never been an issue. Just to make sure, I followed the step by step instructions as per http://technet.microsoft.com/en-us/library/cc706871.aspx. One of the steps used: "stsadm -o setsitelock -url -lock readonly". The backup appeared to complete successfully (as I've done many times before).
   
   
2. Problem was that when my Oakton colleague Paul Rowland moved the site collection over to another virtual machine image (on MS Virtual PC) and tried to restore it, it was impossible to log in. Originally I thought the problem was due to the domain settings being different - but he couldn't log in even after changing the site collection administrator. The account was definitely not locked out and the password was correct as he had logged into and out of the machine with those same Administrator credentials.
   
3. I tried to log back into my original machine (where I made the backup) and I couldn't log into it at all - even Administrator gave "Access denied" on the site.
   

My knee-jerk response was "what on earth did the backup tool do to my backed up site?".

This problem occurrs because the backup process doesn't reset the readonly flag for you (which is fair enough). If you follow the steps exactly, you will have the same issue. What mainly concerns me is that I would expect a user to be able to log in at least - just not to manipulate the site at all - not to be denied completely. In summary, it would appear that there is no real difference between -lock readonly and -lock noaccess when setting a lock on a site. When the site is readonly, you simply cannot log in at all.

So the fix after restoring the site to the other machine (and my original VM image) was simply to set the readonly flag to none via "stsadm -o setsitelock -url -lock none"

After doing this, I also had to reboot for me to be able to log in to the site.

How to allow Anonymous Access to one list (e.g. a picture library) in your SharePoint 2007 site

It is a 3 stage process to enable anonymous access to a specific list in your site (and only that list, not the rest of the site). This is particularly handy if you want to allow users to see images (via the html img tag) in MOSS-generated workflow emails - but don't want to make the whole site public. This is really the equivalent of an unauthenticated /Images directory in an ASP.NET web app).

If you follow the instructions from this article from MSDN under the heading "Enable anonymous access for individual lists", you will realise that the steps under that heading don't work by themselves. That is, you have to perform all steps listed for enabing anonymous access in the site collection and site level before you can enable anonymous access for lists:
http://technet.microsoft.com/en-us/library/cc263363.aspx#Section4.

To enable anonymous access to a particular list on your site, you need to do the following (in this order):

1. Enable Anonymous access for your site collection through Central Admin->Application Management->Authentication Providers->Default-> Check On Anonymous Access
2. Enable Anonymous access for the site through Site Actions->Site Settings->Site Permissions->Settings->Check on Anonymous Access
3. Enable Anonymous access on the list you want available to anonymous users e.g. Site Actions->Site Settings->Site Administration-> Site Libraries and Lists->Click Customize PictureLibrary->Permissions for this picture Library->Settings->Anonymous Access-> Check On the 'View' checkbox.

Note that if you do 2 before 3, you will be presented with a list with all the options greyed out (i.e. you cannot check on "View" permission for anonymous users.)

Windows Workflow Replicator Tasks & The SharePoint 2007 SDK (version 1.4 - August 2008) still doesn't install the ECM Activities into the GAC for you

I'm currently working on an application that creates multiple SharePoint tasks (based on a contact list) as part of a SharePoint workflow. Once all the tasks are completed, the workflow can continue. I recalled that I went through the Contact Replicator sample in the SharePoint 2007 SDK around a year ago and knew that would help me in my endeavours.

However, None of the SDK sample projects compile off the bat. I remember having this issue about a year ago. Again today, I just installed the latest MOSS 2007 SDK (updated August 2008) to find the missing ECM dll issue (or annoyance) is still there. The problems is that none of the sample projects in the SDK will compile until you've:

1. Built the solution (and allowed Visual Studio 2008 to convert it automatically from 2005 format if neccessary)
2. Installed the compiled the ECM Acitivty Library Dll and copied it into the gac (copying it into "C:\Windows\assembly" via Windows Explorer or using
   
   gacutil /i "C:\Program Files\2007 Office System Developer Resources\Samples\Workflow\ECMActivities\bin\Debug\Microsoft.Office.Samples.ECM.Activities.dll"
   
   
3. Close and Reopen any sample projects you had open in Visual Studio.

Seeing as the SDK has a full blown installer, I had hoped the good folks in the the MOSS team would have fixed this problem - but I will have to continue living in hope.

How to Get "Run As" Context Menu in Vista/Windows 2008 for running SharePoint 2007 stsadm.exe

To run the SharePoint Administration tool Stsadm.exe on a SharePoint 2007 server, you must run as a SharePoint Server Farm Administrator - otherwise you will just get a blunt "Access Denied." error message. Trying to run any stsadm command whatsoever will be met with the same terse response. This is because the local administrator (when the database is on a separate server to MOSS) will not have sufficient privileges on your MOSS Content database.

Today, I needed to run stsadm.exe on a Windows 2K8 server. However, I didn't want to log off and log back on as another user every time I wanted to do this. Unfortunately, now Vista and Windows 2K8 "Run As" functionality only supports running as a local administrator - not a specific user anymore (e.g. like the SharePoint farm administrator account defined on another server - in Active Directory). Others have also complained about this issue on Microsoft Connect - https://connect.microsoft.com/WindowsServerFeedback/feedback/ViewFeedback.aspx?FeedbackID=329528

There are 2 options to get around this issue without logging off and on as another user:

1) Use the commandline RunAs tool (if you like a lot of typing or prefer batch files - see my previous entry at http://ddkonline.blogspot.com/2008/06/using-impersonation-batch-files-and.html)
2) Use ShellRunAs. Thankfully, the hardworking guys at Sysinternals have the following tool which allows you to add the Context menu for Run As back where it should be:

http://technet.microsoft.com/en-us/sysinternals/cc300361.aspx

To install this command in the context menu, you can simply use the following:

ShellRunas.exe /reg

Et Voilà! - instant RunAs goodness shall return to your context menu.