Bob's Blog

Custom Assembly Versioning within a K2 Process

Recently I was asked the below question: 

"Let’s say I have a custom assembly that I include in the workflow project.  Later, my requirements change and I produce a new version of both the workflow and the assembly.  Does blackpearl handle versioning my custom assembly?  In other words, workflows using the original assembly can run side-by-side with the new version? "

The short answer is YES, it behaves exactly as described.  The long answer is described below to help in better understaning how K2 works:

 

When you add a reference to a K2 process, the DLL file itself is serialized as binary data to the K2Server database each time you deploy the process.  As such this DLL is now associated with this specific process definition version.  The first time the process is used, K2 Server extracts all DLLs (K2 generated AND referenced DLLs) to the K2 work folder.  This is typically located at:

 

                C:\Program Files\K2 blackpearl\Host Server\Bin\Work

 

In an example I just worked up, I created a process that referenced a .NET assembly called “MyTestAssembly.dll”.  The first time I used this process, it created a folder called:

 

C:\Program Files\K2 blackpearl\Host Server\Bin\Work\Proc241

 

NOTE:  the number 241 relates to the ID for the process definition version.

 

If I look in this folder I see the following:

 

 

 

Here you’ll see all the stuff K2 generates as well as my .NET assembly.  Don’t be fooled by the date of the .NET assembly… remember it had been serialized to the database as binary data, so when K2 lays it back down on the disk it will always have a new date stamp.  If I look at the version info on my DLL I see:

 

 

Ok, now I go and change my DLL and rebuild it.  As part of the change I changed my DLL version to 1.1.1.1.  I then reference in my K2 process and then redeploy.  Now if I look at my Work folder I see:

 

 

Notice that we now have two folders side by side.  ‘Proc241’ was my original version and ‘Proc242’ is the new one.  If I browse to Proc242 I see:

 

 

This looks pretty much the same as above (Proc241), HOWEVER if I look at the version of my DLL I see the new one:

 

 

Thus they should run side-by-side without issue. 

 

Things where handled very similarly within K2.net 2003 so if you are on a legacy project the same knowledge can be applied.
Published Monday, January 14, 2008 2:32 PM by Bob

Comments

 

chrisg said:

AWESOME STUFF BOB!  Thanks

January 14, 2008 10:26 PM
 

gabriel.malherbe said:

Thanks for the article Bob.

How do you best suggest we handle config file settings if your custom assembly requires is?

In 2003 you had limited options that included adding the config settings to the config file of the K2 server. As it was not ideal in deployment scenarios, we often had to rewrite the assembly and pass the config settings into it from the point of call in the process in order to extract the config settings into the StringTable. Do you know is we are better off with this in BP?

January 16, 2008 8:45 AM
 

Bob said:

Unfortunately I am not aware of any options other than the K2.net 2003 ones.

January 16, 2008 9:35 PM
Anonymous comments are disabled