Due to problems we found with the restore of sites/site collections using stsadm (our tasks generated from workflows were not restored), we've taken a different route for backup/restore. We plan a major customization to our SP site and want to take a backup so we can rollback in case the install fails. In our System Testing (not production) environment, we've backed up the 12 hive, the virtual dir's that the IIS points to SharePoint, and the SharePoint databases in SQL (using SQL server to do the db backups).
We have custom event handlers and workflows built with Visual Studio, and deploy the dlls to the GAC as version 2 (signed and versioned in Visual Studio). So when we deploy, the GAC will contain 2 versions of the workflows – version 1 and version 2. During the deploy we use SP stsadm features to install/activate the WF's. We also go to each library and add the new, version 2 WFs. This automatically sets the version 1 WF's to "Not Allow" new instances (which is what we want) and the version 2 as active – perfect so far.
When we've completed the install, we then assume a failure and attempt to restore to the same machines (SharePoint on one server, SQL on another). We start by uninstalling the version 2 WF's from the GAC, reset IIS (to clear cache of these ver. 2 WF dlls'), restore the 12-hive and virtual directory folders, then restore the SQL dbs. This is all just as manual as you read it – no stsadm here. All seems to work after our restore, it appears the restore was successful – the mods we made to column names, data changes, etc during the install are all reverted back to the original pre-install state. With one exception. When we run a workflow, it always fails and the Logs in the 12-hive indicates the WF is still trying to use the version 2 of the dll (System.IO file not found error) We think we've backed up and restored all the moving pieces of Sharepoint but we're missing something here, does anybody have any ideas why the version 2 WF dlls are still being referenced eventhough we restored all the folders and db's of SharePoint?
Thanks,
Kevin
Best Answer
Kevin,
If I'm properly understanding your order of operations, I have one big question: are you restoring content databases but leaving the farm configuration database (and other databases, like SSP databases) intact during your restore? If the answer is "yes," then I suspect that SharePoint is throwing a fit because your configuration database still maintains a reference to v2 of your workflow. Here's what I suspect might be happening.
When you install a Feature to your SharePoint farm, the SPFarm.FeatureDefinitions collection (which is maintained in the farm configuration database) is updated to reflect what you added. This includes all the standard information you'd expect your Feature to contain: name, scope, ID, version, etc. It also maintains FeatureReceiver assembly information and a RootDirectory value, amongst other things. The RootDirectory property points to the folder in the 12-hive where the Feature manifest is located for the Feature.
When you add your v2 workflow Feature to the farm and activate it, the configuration database is updated. Even if you restore a pre-v2 workflow version of your content database, the farm is still going to be looking for v2 of your workflow because of the Feature association that is maintained at the configuration database level. If the v2 Feature folder still exists in the 12-hive and its manifest points to the v2 assembly in the GAC, it's easy to see where problems might arise.
At the same time, if your workflow Feature leverages a FeatureReceiver, that information is also stored (in the configuration database) in the ReceiverAssembly property of the FeatureDefinitions collection when the Feature has been installed.
If I'm mistaken and you're actually restoring your entire farm in-place (including configuration database), then what I've written doesn't apply. In that case, I would be left scratching my head a bit, too. :-)
I hope this helps!