Hi Dean,

I don't think there is a way to deploy the code module seperately so you will have to deploy at least one process that uses it. 

However you can try the following: In the deployment screen, do not select any processes to deploy/export and then export to the server. Then run a new process to test if your changes were deployed. Remember that it will only apply to new process instances started, and not old running process instances.

I know that in the past I have seen that this does export changes to your destination queues, so it might do the trick for you...

Wow I didn't know about this that you could just export code modules.   I just did to try it out, so how does the latest module release tie to the version of the process?   

If it only applies to the new process instance, and if I go to Version tab and set a previous process version as default, would it have used the "latest" code module I deployed?

Otherwise the latest process version has 2 versions of code modules (the running process ones use the old code module), and new workitems use the new code module.

If it applied to ALL running workitems of current process (similiar to changing code in Repair), then I think that would solve the issues of not able to fix the code for existing running process.   That would have been a great help.

I tried deploying just code module and start a new workitem and it did not make use of the code module I just deployed.  

I then deployed the process and the new workitem does make use of of changed code module.

I don't know if exporting the code module does anything by itself??

Even though one can "export" new versions of the code modules, I dont believe that it makes much sense as code modules are compiled to assemblies and then deployed as part of the process definition.

That's also why Peter got the behaviour he did. One should remember that Code Module methods' input paramaters may change between versions and as such they are "partnered" with specific versions of processes.