Referencing dll’s from your K2 process

10 Mar

I’ve been having a lot of fun (not really) working with external dll references from K2 processes. There’s a light at the end of the tunnel but it helps to know what’s going on behind the scenes when you reference a dll from a process.

Here’s my situation: I needed to integrate a very complex hierarchy of dll’s so that I could access application data from the process (and wrapping them in a service wasn’t an option for me). Obviously I didn’t want to add references to all the dll’s (there are many) so I came up with a great idea – I’d add a class library which references all these dll’s (kind of a proxy class) and then reference only this one dll from my process. Great idea, yes. Successful, no.

To explain why it didn’t work I’ll first explain what happens when you reference a dll from a process. You’ll notice that ‘copy local’ is checked by default. This is because when you deploy the workflow, the referenced dll is sucked into the process and deployed to the database along with the process definition. Then, when you start the first instance of this process, the process definition is unpacked and a temporary folder is created in the HostServer\bin folder, and your referenced dll is copied into the temporary folder. (Side note: note how nicely versioned this is. If you have different version of the process running, each version will have it’s own temporary folder with the version of the dll that the process was deployed with. There’s an excellent blog about this here if you can access it).

So here’s the first important point: only the referenced dll is deployed with the workflow. NONE of the dll’s the referenced dll relies on are deployed, even of those dependent dll’s have ‘copy local’ set to true. So in my case I had a proxy class deployed but the actual dll’s I was trying to use were nowhere to be seen.
So what’s the best thing to do? You have 3 options:

  • Reference all the dll’s from the process (not my preferred option)
  • Copying the dll’s to K2’s bin folder
  • Deploying the dll’s to the GAC
  • Overall deploying to the GAC is your best option if you can. Or of course you can wrap the dll’s up in a service – this would have been the cleanest option but in my case this option wasn’t available because we needed to tweak every little bit of performance out of the system that we could.


    Posted by on March 10, 2011 in .Net, K2 Workflows


    5 Responses to Referencing dll’s from your K2 process

    1. Kim

      June 3, 2011 at 4:40 pm

      Hi there,

      Have you experienced your referenced dlls not updating when the dll is updated?

      I’ve tried removing/readding the reference, and that did not work. A few days later, my references updated again for some reason.

      Appreciate your help!

    2. Trent Jacobs

      June 3, 2011 at 4:59 pm

      Hi Kim,

      I haven’t had this with K2 yet, no. Have you checked in the temporary folder in [HostServer\bin] to check the dll version? If the old version is still being deployed, try setting ‘copy local’ to false and put your referenced dll in K2’s bin folder and giving that a try.

      Also make sure that the version of the process/dll you’re checking is the latest one. If ‘copy local’ is true then the dll is versioned along with the process, so any live instances of older processes will still be copying the older dll into the temporary folder. If that’s the case you’ll see a number of temporary folders in HostServer\bin folder – one folder for each version with live instances.

      Let me know how you get on?

    3. Carlos

      June 16, 2011 at 5:58 pm


      Have you checked the obj folder, in your K2 project folder. K2 may have placed the assembly in there when you first referenced it.


    Leave a Reply

    Your email address will not be published. Required fields are marked *