I' have a process that goes like this: Build server takes the latest version of workflow from repository, creates deploument packages and deploy it to a terget server.
I've performed the followings for an upgrade to 4.7:
I have upgraded the workflow after upgrading k2 version from 4.6.11 to 4.7. Checked in the workflows in the repositoy.
Updated the target test environment k2 version to 4.7.
When the build server tries to create deployment packages for the terget test server, it get an : Error - Invalid archive type
What might cause this?
The build server has a older version of k2 (4.6 / 4.12060.1560.0) and .net version 4.6.
But its working fine if the terget test server has other version of k2 like 4.6.9 or 4.6.11
So it doesn't seems like its a problem caused by the missmatch in k2 version. One thing is that now we need .net framework version 4.6.1 to run k2 4.7. Could this be something?
Really stuck with this since yesterday. Any discussion is appreciated. Thanks.
1. Are you creating the package using the Package and Deployment tool from a client machine or from the Server?
It could be that the package and deployment tool version does not match the version of the K2 server (perhaps 4.7 tool connection to 4.6 server). Sometimes a mis-match in version may not error, but it is recommended that the K2 version matches.
Thank for the replay.
No, Im not using the Package and Deployment tool. Not sure what you meant by client machine though. Im using a custom project .exe file that is using msbuild to create and deploy the project from the build server.
The commands looks like this:
For Creating package:
libk2build.exe create_package %k2server% 5555 MyWorkflow.k2proj "PackageDestinationPath"
here, libk2build.exe uses k2 4.6 version's dlls:
create_package is a parameter, 5555 is the terget server's port ect...
This fails if %k2server% is my target test server (has k2 4.7)
This success if %k2server% is my build server (has k2 4.6) - All the commands are being executed from this server as well.
And for Deploying package: I was trying to create the package having the build server as a terget machine since it succeed and then deploy it to the test server by manually editing the "server" parameter in the MyWorkflow.msbuild file. But it fails.
%MsbuildPath% MyWorkflow.msbuild /p:Environment=PRODUCTION
* Something else which is strange as well....
We have several test servers test servers running differnt versions of k2. If i browse to k2 workspace > Management Console for my machine, i can see all the list of all the k2 servers we have. I can also browse to all of these k2 servers and their child nodes.
But i've noticed today that i can't browse to any server that runs lower than 4.7. This has happen after the upgrade. For example i can not browse to server that has k2 4.6.6 or 4.6.9 or 4.6.11. I could do this when i had 4.6.11 before my upgrade to 4.7. This is strange since it should have backward compatability?! right ?
If browse to the k2 workspace url of my build server, then i can perform te above on all k2 servers except the ones that has k2 4.7. Which i initially thought was not too shocking since in this case i am trying to access the management console of a server with a higher version.
Forgot to mention the most interesting part. When i try to browse to other servers management console i get the same error that i was getting while trying to Create the Deployment project. see attch.
As far as I can tell there is no backwards (or forwards) compatibility in the K2 tools (package and deployment, smartobject tester, etc) in regards to connecting to servers of differing major versions (4.7>4.6 or vice versa). There IS backwards compatibility in opening and deploying packages created with older tools, but the packages must be opened and deployed using the same version tool as the target server. I think if you need to have different version servers using the same packages, you're going to need to have both a 4.6 and a 4.7 build server to deploy them.
Thanks for the reply Shawn. I had assumed that the libraries needed to match the server version. What caught me was that I had forgotten the build process extracts environment config from all our environemnts and at this stage production is still behind a version.
My resolution is to comment out the production environment setup until we upgrade to the latest version.