Photo courtesy of Neatorama

2 weeks ago I had a seemingly crazy idea. I challenged my colleagues at imason in a contest to see who could last the longest without taking the elevator. Considering we’re on the 8th floor of our building, I figured there wouldn’t be a myriad of people lined up to enter the contest.

Boy was I wrong.

15 people entered the contest, and in the last 2 weeks, imason employees have walked up and down approximately 47,250 stairs.

imason’s employees are so dedicated that some are even riding their bikes to work and carrying their bikes up 8 floors.

Not only is this challenge good for the environment, but it’s also great for everybody’s health. I’ve long been an advocate for active, healthy living and I believe strongly in treating the earth well. This is one simple thing that we can do to help make a small difference.

One thing I don’t know is how long this contest will last. But I can honestly say that I hope it continues for many months to come.

I’m in it for the long haul.

Could this be the latest Service Pack for Vista??

At first glance, Windows Workflow does a good job of persisting workflows to the database for long-running State Machine Workflows.

However, what happens when you update your workflow assembly? Windows Workflow will try to retrieve the workflow from the SQL Persistence store and de-serialize the object, but it will throw an exception (You’ll see a SerializationException or IndexOutOfRangeException).

There are different ways to handle this situation. The first (and most obvious way) is to set versions on your DLLs so that the workflow will de-serialize into a previous version of a workflow and continue running in the older version. But what if the change you made to the workflow fixes an important bug in the previous version? In this case, you may want  your previously persisted workflows to use the new version of the code.

A few quick Google searches will lead you to a few different options in handling this situation:

• Using an assembly resolver or using the “AppliesTo” attribute [1]
• Dynamic Workflows [2]
• Breaking up into smaller workflows [3]

None of these options are particularly appealing to me, so I had to find a better way to handle updates to the workflow code but still allow my long-running workflows to operate.

My “outside the box” solution: Workflow Rehydration

To achieve Workflow Rehydration, I’m keeping track of the current state in a SQL database and if the current workflow can’t be de-serialized (because the workflow has been updated), I instantiate a new workflow and I set the state to the state it was previously in.

The obvious concern that comes up using this approach is “how do I avoid executing the code inside my StateInitializationActivity?”

To get around this issue, I’m passing in a boolean parameter into my State Machine workflow that indicates whether or not the workflow is being rehydrated. I then use an IfElseActivity to execute my State Initialization code only if the workflow is not being rehydrated.

The end result is that the workflow goes back into its previous state, but it’s now running inside the new updated workflow code. You might call this a “Utopia State” (Apologies for the lame pun).

The end user has no idea that the workflow has gone through this transformation from an old version of the workflow code to the new version; and it only took a little bit of code along with some IF conditions.

References: 

[1] http://msdn.microsoft.com/en-us/library/aa349375(VS.85).aspx

[2] http://community.bartdesmet.net/blogs/bart/archive/2006/08/28/4322.aspx

[3] http://www.sitechno.com/Blog/WorkflowVersioningOfLongRunningProcessesSucksHereIsMyTakeOnIt.aspx

Seeing my Google Account dashboard made me realize how much I depend on Google:

A few thoughts came to mind:

• Google sets the bar very high. They provide high quality products (mostly for free), amazing feature-sets (Google Analytics amazes me), and they always provide a great user experience. It’s very rare that I’ve seen errors in a Google application

• Many Google products are a product of acquisitions. It’s amazing how so many acquired products can be re-factored, seamlessly integrated, and branded to become part of the Google product-line.

• I consider the successes of Google a lesson for me and others in Consulting. If we strive to set the bar as high as Google, we can have a dramatic impact on our clients and build great solutions.

I’m only using a small subset of Google applications. Look some of the other applications that are available:

Not to mention the new applications that are always being developed in Google Labs:

Google’s contribution to the explosion of the Internet is as important as Microsoft’s contribution to the explosion of Personal Computing. Google will continue to build great applications and constantly raise the bar to provide end users with amazing options.

My first memory of Google applications raising the bar (Aside from Google Search) was on June 30th, 2004 when I observed Microsoft raise the Hotmail mailbox limit from 2MB, YES, 2 MB!! to 250MB!

On my current SharePoint/InfoPath project, we’re using NAnt to deploy absolutely everything. NAnt creates SharePoint pages, imports web parts to pages, activates SharePoint features, deploys assemblies, creates SharePoint lists, creates/updates SQL databases (via DBDeploy), packages and deploys InfoPath forms, copies XSLT/XML/ASPX files, and much much more.

I always boast about how when a new developer comes on the project, he/she can have a fully operational SharePoint development environment within minutes. This is an important achievement, as most SharePoint Developers know it can be painful to automate deployments to SharePoint sites.

This works great for a Development environment, but what happens when you need to deploy to Production? Some companies don’t allow NAnt to be executed directly in Production, so you’ll need to setup your NAnt build files to execute on a build server to prepare for a Production deployment.

To achieve this, I went back into my NAnt build file and updated my NAnt targets to allow for the “preparation” of a deployment rather than actually performing the deployment. This provides us the ability to run NAnt on a build server in order to package everything for an easy automated deployment in Production (without NAnt).

I’m leveraging Windows Installer XML (WiX) in order to package the deployment files into MSI packages (In a future post I’ll get into more detail about using WiX MSI’s for SharePoint deployments). For SharePoint feature installation/activations and InfoPath form deployments I’m generating a batch file from NAnt that gets packaged into the MSI and executed when the MSI is installed on the server.

First we prepare the batch files – this will create 3 new empty batch files with a line “ECHO OFF” inside them:

   1: <target name="PrepareBatchFiles"> 

   2:     <echo file ="${featuresDeployment.cmd}" append="true" message="ECHO OFF" /> 

   3:     <echo file ="${formsDeployment.cmd}" append="true" message="ECHO OFF" /> 

   4:     <echo file ="${dataConnectionsDeployment.cmd}" append="true" message="ECHO OFF" /> 

   5: </target>

Next, we append STSADM calls to the batch files – anytime we call STSADM from NAnt, we will add a row into the batch file. Here’s an example when we’re calling the “UploadForm” NAnt target:

   1: <target name="UploadFormTemplate" description="Uploads an InfoPath Form">

   2:     <choose>

   3:         <when test="${prepareDeployment=='true'}">

   4:             <echo file="${formDeploymentBatchFile}" append="true" message="echo Attempting to upload form template '${formName}.xsn'" />

   5:             <echo file="${formDeploymentBatchFile}" append="true" message="${stsadm.exe} -o uploadformtemplate -filename &quot;${deploymentFolder}\Forms\${formName}.xsn&quot;" />

   6:         </when>

   7:         <otherwise>

   8:             <exec program="${stsadm.exe}">

   9:                 <arg line="-o uploadformtemplate" />

  10:                 <arg line="-filename &quot;${publishedFormsFolder}${formName}.xsn&quot;" />

  11:             </exec>

  12:         </otherwise>

  13:     </choose>

  14: </target>

You can see from the NAnt target above that  it checks whether we’re “Preparing” a deployment or if we’re actually deploying. If we’re preparing the deployment, it will generate batch files and copy files to a deployment folder. I’ve added the “choose –> while” condition into each NAnt target so that I can prepare my deployment files for the MSI.

The generated batch file will look something like this:

   1: SET STSADM=C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\STSADM.exe

   2: ECHO OFF

   3: "%STSADM%" -o deactivateformtemplate -url http://sharepoint-serv -filename "C:\MyForms\MyInfoPathForm.xsn"

   4: "%STSADM%" -o removeformtemplate -filename "C:\MyForms\MyInfoPathForm.xsn"

   5: "%STSADM%" -o execadmsvcjobs

   6: ECHO Attempting to upload form template 'MyInfoPathForm.xsn'

   7: "%STSADM%" -o uploadformtemplate -filename "C:\MyForms\MyInfoPathForm.xsn"

   8: "%STSADM%" -o execadmsvcjobs

   9: "%STSADM%" -o activateformtemplate -url http://sharepoint-serv -filename "C:\MyForms\MyInfoPathForm.xsn"

Now when I add a new form to be deployed, it will be automatically added to the batch file for the Production deployment. The end result is that I can run my NAnt scripts on a development environment to actually deploy my SharePoint components, or I can run the same batch scripts on a Production server via an MSI package.