Hacking the Work Folder (or, an alternative method of error repairing)
Sometimes, you can manually hack the Work folder for running process instances to, for example, replace a broken version of a referenced assembly with a fixed version. To begin, review Bob’s posting on the work folder and versioned assemblies:
http://www.k2underground.com/blogs/bobblog/archive/2008/01/14/custom-assembly-versioning-within-a-k2-process.aspx
During process execution, K2 server creates a folder inside Host Server\Bin\Work for each version of the process definition. Any referenced assemblies are also copied to this folder. This is important – even if the assembly is in die server’s bin folder, it will still be copied to the work folder – the only difference is that instead of the version of the assembly in the DB, the version from Host Server\Bin will be used.
Now, suppose you have a process in error state, and the error occurs because of a mistake in the version of the external assembly that the process definition uses. You want to update the assembly, but just copying the new version of the .dll to the Host Server\Bin folder does not do the trick, and you cannot export a new version of the process since the assembly version would then be bound to the process version. Aha - the key is that you need to copy the fixed .dll to the Host Server\Bin directory, and delete the Work folder for the specific version of the process definition.
So, firstly you need to map the process in error state to the version of the process definition. If you open the K2Server.dbo._ErrorLog table, look for the process in question, and make a note of the ‘ProcID’ value. This is the process definition ID.
Now, head over to your K2 server, and locate the ProcNN folder in the Host Server\Bin\Work folder, where NN is the ProcID you just got from the DB. You can try to manually copy the assembly from Host Server\Bin to this folder, but chances are it will fail since the assembly is in use by Host Server. Fear not, just stop the Host server and delete the work folder. The next time you try to repair the error, K2 Server will realize that there is no Work folder for this specific process definition, and recreate the ProcNN folder, using the version of the assembly that lies in the Host Server\Bin directory. Hey presto!
Update: We have also proven another point - you can also directly fix errors in cs- and winwf- code behind in a workflow, by replacing the Context-xxxxxxx.dll and CSWinWF-xxxxxxxx.dll in the work folder or in the host server bin folder, and repairing the error. This is a slightly more complex process, and you really need to keep your wits about you, but it's a lifesaver if you cannot use studio to repair error on the server for whatever reason.
Neil 'H@xx0r' and Conrad