Monthly Archives: March 2011

K2 and .Net 4

Using K2 in a .Net 4 environment is fairly simple, but there are 2 things you need to do to get it to work.

Edit Config Files
  1. Open K2HostServer.config file and add this to the <appSettings>:
    <add key="netfxversion" value="v4.0.30319" />
  2. Open the K2Server.config file and change the .Net version to read as follows:
    <Framework Version="v4.0.30319" />
  3. Open K2.Setup file and change the .Net version to read as follows:
    <Framework Version="v4.0.30319" />
  4. Restart the service
But if you are using a config file…

This came as a bit of a surprise. If you’re referencing a dll which uses a config file then you need to add a reference to this config file in K2HostServer.config because the dll will be loaded in the K2 services’ context (See this post for more about how to do this). The problem is, however, that as soon as you’re referencing a .Net 4 dll this doesn’t work anymore. After much searching, hacking and frustration I found a workaround. Here’s what you do:

  1. Create a config file in the same folder as K2HostServer.config. Name it K2HostServer.exe.config
  2. Add your config file reference to K2HostServer.exe.config and not K2HostServer.config.

Voila. It works. I raised a ticket for this and it seems this is a .Net bug – read here and here for more info.

Hope that helps!

Update: I have verified my approach with K2 and they have confirmed that this approach is both supported and will be the recommended approach.
Another Update: This will work if you’re referencing dll’s from your processes but not if you’re referencing dll’s from a custom security provider. If you’re referencing dll’s from a security provider, you need to add the config entries in K2HostServer.config, not K2HostServer.exe.config.


Posted by on March 23, 2011 in SmartObjects


Referenced dll’s and config files

In this post below I spoke about what happens to the dll’s you reference from a K2 process. This gets more complicated if you want to include config files with your referenced dll for 2 reasons:

  1. Even if K2 deploys your dll for you (‘copy local’ is set to true) the config file will not be deployed.
  2. You can manually copy your config file, but it won’t be loaded (and will be deleted whenever the K2 service restarts).

If you want config entries to be read you have to use a more roundabout way of getting them. The simplest way of doing this is to add the config settings into the K2HostServer.config file and then restarting your K2 service. This is risky though because each time you upgrade K2 your changes will disappear (OK not always, but most times). A nice compromise I’ve found is to merge the config files:

  1. Copy your config file (mySettings.config) to K2’s Host Server\Bin folder.
  2. Edit K2HostServer.config so that <appSettings> becomes <appSettings file=”mySettings.config”>
  3. Restart the K2 service
Leave a comment

Posted by on March 15, 2011 in SmartObjects


Referencing dll’s from your K2 process

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