10-19-2009 10:22 PM
We have a custom application running at a client site, version 1.0 with COD files name "myapp-10.cod". It contains four COD files, and was deployed via the BES (using an ALX file). All was fine and everyone was happy. The application was deployed to about 300 users.
When it cam time to upgrade to version 1.1, we renamed the COD files to "myapp-11.cod". The internal project name remained the same. We did some testing on devices by deploying via a URL download (using the renamed COD files and a JAD file). The application upgraded fine, and again, the test users were happy.
When it came time to deploy the upgrade via the BES, it was a disaster. The BES didn't recognize the new version as an "upgrade", and instead, pushed out a SECOND application. Now, users had version 1.0 AND version 1.1 running on their devices?
I was told by our technical partner rep that this is "possibly" due to the fact that the COD files were renamed.
Can anyone confirm this? I was always led to believe that the physical file names were irrelevant, as long as the internal name (the <application id> tag in the ALX file remained the same.
How does the BES recognize an "upgrade" vs. a new application?
10-20-2009 03:11 AM
10-20-2009 03:52 AM
I believe you have a problem not just because you've renamed the COD file, but because your naming convention is not acceptable for BlackBerry modules. If I'm not mistaken, BlackBerry modules must not have dashes in their names. This is because dashes are reserved for naming sibling modules (when a module is too big, it's split into <module.cod> <module-1.cod>, <module-2.cod> and so forth). Various installation methods (web OTA download, Desktop Manager, BES OTA Push) interpret these dashed names a bit differently. I recall in BES 4.x there was an issue where the push subsystem would hate dashes whereas the software configuration/IT Policy subsystem would require them.
To make the versioning work OK, you should leave module name untouched, and simply change the version that's built into the module (version and vendor fields can be specified both on per-project and per-workspace level). You need to ensure that the same version is also specified in the JAD and ALX files. In this case the various deployment mechanisms will recognize your new module as an upgrade for the old one.
10-20-2009 08:28 AM
Simon_hain, posting to the BES section of the forum was my initial thought, but when we first alerted RIM about this issue (via TSupport), they told us it's a Development issue (an incorrectly formatted ALX file). Anyway, we did remove the old app using a new SW config.
The names of the files are actually "myapp11.cod", "myapp11-1.cod", "myapp11-2.cod" and "ksoap.cod". There were no dashes in the name, my original posting was incorrect. The files were generated directly from the JDE, they were no renamed "manually". In fact, the Build screen allows you to enter the version AND the output file name. There's no indication anywhere that the output file name has to be the same as the internal Project Name.
As an aside, if dashes are supported, the JDE shouldn't allow you to include one in the name.
10-20-2009 08:44 AM
10-20-2009 10:37 AM
10-20-2009 11:37 AM
10-20-2009 12:26 PM
Well, there's also application ID in the ALX file. I'm not sure how much of this ID the BES uses, but it does use it sometimes, if I recall correctly... Might it have to do with the name of the module group on the device?