Tuesday, May 20, 2008

PowerShell for Flexible Iterative SharePoint-based Development


This post by David Mann is a good resource for 3rd-party and MS tools to help with SharePoint-based software development:

Using Tools to make SharePoint Development Easier

While we here at the SharePoint Solutions Software Division certainly use some of the tools mentioned in David’s post, I guess maybe our development requirements are a bit "heavier" than the typical IT project since we're developing packaged products for commercial redistribution. We need the fined-grained control of a flexible, highly re-usable tool-chain.

Our developers use PowerShell extensively for various iterative "build and deploy" scenarios. For example, here's the usage menu from a PowerShell script called Deploy-ExCM which we use while working on our ExCM product:

----------

PS C:\usr\src\devteam\ExtranetCollaborationManager2009\Mainline\Dependencies> .\deploy-excm -u

Deploy-ExCM
Build and deploy utility script for Extranet Collaboration Manager

Deploy-ExCM usage information.
Arguments:
-i Recycle IIS application pool
-a Deploy artifacts (xcopy)
-g Deploy assemblies to GAC
-b Build solution (devenv)
-fui Uninstall / Install Features
-fda Deactivate / Activate Features
-bcl Update BCL assemblies to GAC
-testweb Delete and recreate test web
-wsp Build WSP package (makecab)
-light Light deployment -a
-heavy Heavy deployment -b -a -g -bcl -i

Examples:
deploy-excm -a -b -i -g
deploy-excm -b -g
deploy-excm -a -i -g -testweb -fui

----------


In our development environments, each developer using this script has a few environmental variables set in his/her Microsoft.PowerShell_profile.ps1 profile:

----------

#
# User-specific settings
#
write-output "`nSetting environment for SharePoint Solutions development.`n"
$WorkspaceRootDir = "C:\usr\src\devteam"
$PowerShellLibDir = "${WorkspaceRootDir}\DeveloperCenter\PowerShell"

# ExCM
$VBL_ExCM = "Mainline"
$BuildConfig_ExCM = "Debug"
$AppPool_ExCM = "SharePoint - 8081"
$AppRoot_ExCM = "C:\inetpub\wwwroot\wss\VirtualDirectories\8082"
$SiteUrl_ExCM = "http://devapp08:8082"
$WebUrl_ExCM = "http://devapp08:8082/downloadstest"

---------


The wide range of flags and parameters for Deploy-Excm make it a flexible and convenient tool for use while we work on the various types of artifacts involved in a SharePoint solution package. For the most common iterative build scenarios, I call the utility directly from the Visual Studio Tools menu as an External Tool. The three permutations I've added there are:

Deploy-ExCM (iterative) - this calls deploy-excm -a -i -g
Deploy-ExCM (heavy) - this calls deploy-excm -a -i -g -testweb -fui
Deploy-ExCM (makecab) - this calls deploy-excm -wsp

For your reference, here are the PowerShell scripts we're using.

1. Profile - contains developer-specific variables, pathing modifications, and PowerShell translation of vsvars32.bat:
http://www.codekeep.net/snippets/9ba5c3c9-87ea-44f2-81cd-7466f982caaf.aspx

2. Shared Functions - re-usable functions
http://www.codekeep.net/snippets/c3069a2f-3027-496c-8d0a-94e1a0894cfb.aspx

3. Deploy-* - product/project specific calls, command-line parsing:
http://www.codekeep.net/snippets/8071237c-fb1f-4426-96bb-1b4b75f96631.aspx

We try to have a "Deploy-*" script for each major product/project we work on. By sourcing PowerShell include files, much of the internal functions are re-used across scripts. If anyone has questions, feedback, suggestions or would just like to discuss further, please leave your comments and we'll start a dialog.

Monday, May 19, 2008

Does the !New tag annoy you?


Are you a bit sick of that !New tag that appears beside a new item uploaded to a library? Well, you are not alone. I am repeatedly asked this question in our Applying SharePoint 2007 Core class: "How do I get rid of that annoying !New tag?" or "How long does an item really stays new?" J. Usually students ask these questions because they have uploaded/migrated a bunch of documents from their file share which are not really "new", but they get the !New tag assigned to them anyway.






Ok, so here are the answers:
First of all, this feature applies to not only Document Libraries, but also to other Lists such as Tasks, Issues, Contacts, Links etc. In the default installation of SharePoint, the "!New" tag gets appended to every new item in SharePoint lists and remains there for one calendar day. An administrator who has access to the SharePoint server has two options when changing the behavior of this feature:
  1. Increase the number of days the icon should appear beside a new item in the list
  2. Eliminate the appearance of the icon altogether
The stsadm.exe utility (located in the SharePoint server) is used to accomplish this task. Navigate to stsadm's location using a command prompt:
..\program files\common files\microsoft shared\web server extensions\60\bin
The "setproperty" command will be used for this task as follows:
stsadm.exe –o setproperty –pn days-to-show-new-icon –pv (number of days) –url (Virtual server address)

For example, use the following syntax to prevent the new tag from appearing:
stsadm.exe –o setproperty –pn days-to-show-new-icon –pv 0 –url http://(your server name)

Hope this helps!

Tuesday, May 06, 2008

Looping Through Items in a SharePoint List with SharePoint Designer Workflows


One of the things that most frustrates me about SharePoint Designer workflows is that there is no convenient way to write loops. Not only can we not create For…Next, For…Each, Do…While, and Do…Until loops within our workflows, but there is no obvious way to loop through items in a list.
The Scenario
For example, assume you have a document library with 1,000 documents in it. You have just written a workflow with SharePoint Designer to e-mail the document creator and have him or her enter certain pieces of metadata. This will work fine for new documents going forward, but what about the 1,000 documents that already exist? You certainly don't want to have to start all those workflows manually!
The Solution
You can accomplish this automatically by setting the workflow on the library to run whenever an item is changed. Then write another workflow on another list to cycle through all the documents in this Document Library and set a processed flag to both indicate which ones have been processed.
Getting the Library Ready
First, you need some way in the document library to identify which items have been processed—that is, on which items your workflow has already initiated the workflow. You can do this by adding a custom column named "Processed", of type Yes/No (checkbox), with the default value set to "No".
Second, you'll need to modify your workflow to run when an item in the library changes. If you don't want the workflow to run every time an item changes, but only when a new item is created, you may want to check your new Processed flag at the beginning of your workflow and have your workflow set it to "Yes" after it runs.
Writing the Loop Controller
You will need another list on which the Loop Control workflow will run. I prefer to use a custom list named "Loop Controller". I also add a field to track the ID of the last processed item. This column serves two purposes: we can change this value to re-run the workflow and it also serves as a gauge to show how far along the loop controller is in its process. This field is just a number field and you can name it "Last Updated Item" with a default value of "0".
Now you are ready to write a workflow on the Loop Controller. It should be set to run manually and when an item changes.
The workflow will not have any conditions, but will have several actions together:
  1. Look at the Document Library and get the ID for the first item that does not have its Processed value set to Yes. Store the ID for this item in a workflow variable named CurrentItemID.
  2. Change the value of the Processed field for the item in Document Library with the ID equal to the CurrentItemID. This change will cause the workflow on the Document Library to run for that item because you wrote the workflow to run when an item changed.
  3. Update the value in the Last Updated Item column on the Loop Controller list item. The workflow will stop after this action. However, because the item changed, and the workflow is set to start when an item changes, it will kick-off a new instance of the workflow. Through this stopping, restarting, and setting the Processed flags, you have created a workflow that will loop through the items in the Document Library.
Your completed workflow on the Loop Controller will look something like this.




Once you have finished writing the workflow on the Loop Controller list, you just need to add a new item and manually start the workflow.
If everything worked properly, then you can refresh the view of the custom list and watch the value in the Last Updated Column increase as it loops through the items.


You will notice that once the workflow can no longer locate an item in the Document Library with the "Processed" field equal to "No", the workflow will error out and stop. That's OK, because you want it to stop, otherwise you would have an infinite loop.
If you look at the history of the Loop Controller workflow, you will see where it ran once for each document in the Document Library.




If you look at the Document Library, you can see the workflow for each item was initiated when each item's "Processed" column was updated to "Yes".


When you are finished using the Loop Controller you can just delete the list and workflow.
Looping Inside a Workflow
Using this same technique of changing a value on an item, you can create workflows that run multiple times. You can even set a value in a column to act as a counter to control the number of times it runs. In some cases, by using conditions, you can simulate simple loops within a SharePoint Designer workflow.
Enjoy!