Hi,
My package uses no capabilities at all and I have a Publisher ID and Certificate.
Can I somehow sign the package without paying anything, or do I still have to pay the 10 Euro fee for the Express Signing procedure?
Thanks,
Nadav
Hi,
My package uses no capabilities at all and I have a Publisher ID and Certificate.
Can I somehow sign the package without paying anything, or do I still have to pay the 10 Euro fee for the Express Signing procedure?
Thanks,
Nadav
hello,
you don t have to pay for self signing or for siging with your certificate
if you have got unsigned sis file just type in your command line console: singsis -h
and you will get information what do you have to pu in console to sign sis
good luck
Yes, if you want to have your application Symbian signed, you still have to pay for it. Actually what you pay for are not the capabilities, but the usage of the infrastructure (SymbianSigned still has to validate that you are you, etc.).
If you can live with self-signing, that is totally free, however the user will get a notification about untrusted supplier.
OK, thanks. Maybe you can also answer this one:
We distribute our software via various channels, and we would like our software to identify the channel it came from. Also, we would like to ship our software with different "flavors", which differ from one another only by static resources (text files, pictures, etc.).
However, we wouldn't like to send each "flavor" for signing, as it costs a lot of money and also takes time.
So what we thought doing is to sign the core application once, and then create wrapper packages that install the core application as an embedded package and also install some static files. This allows us to use Express Signing for the wrapper packages, which is much quicker and cheaper.
Only problem is that if the user uninstalls the core application, the wrapper package does not get removed and it is left on the phone.
Is there a way to solve this problem?
Thanks,
Nadav
Am I right if I suppose that the "core" application could not be Express-signed?
Yes, certainly. The core application is fully SymbianSigned.
Unfortunately I have no ideas for such case. If your core app could be Express-signed you could simply leave out the embedding magic, and sign the whole application in a single step.
I will try this idea:
- Make the core application hidden.
- Make the wrapper package add the core application's icon to the menu and start the core application when the icon is pressed.
Thanks,
Nadav
There is a problem: I doubt that you will get certified signing for an application which can not be started in itself (since you either hide it or do not provide the registration file at all).
Does your main application require any capabilities or waivers that would make passing Certified Signed mandatory?
-- Lucian
wizard_hu_, I will supply a wrapper to test it with. Hope it will be OK.
Lucian, yes, my application requires quite a few capabilities, including NetworkControl.
But I must wonder: Why isn't there a simple way to do such things? Why do I need to pay for multiply signing the same application, just to change a picture or text?
wizard_hu_, just to update you that the test house has agreed to sign the application when it is hidden. They only require us to send them a test package that does have GUI.
Cheers,
Nadav
Last edited by nadav_smilansky; 2008-11-05 at 11:29.
Thank you for sharing, this info is important to many other developers I guess.
Although the solution is feasible, it has some problems:
- It causes more pop-ups during installation
- It still requires express signing, which is not free.
What we now think of doing is renaming the sis file differently for each distribution channel (or for every user download) and then read the sis file name during installation.
I have found that the actual sis file is stored during installation either under E:\ or under C:\Data\Installs, and I've successfully read its name in the install script which I run from the pkg file.
However, I've noted that if I wait a little before running the script, then the sis file is removed. This means the installer does not wait for the install script to complete.
What I need to know: Is the sis file deletion delayed deliberately by the installed, or is it just a matter of the time it takes for the installer process to complete after it launches my install script? In the latter case, this whole method relies on race condition, so it is a bit scary.
OK, discovered an answer to this problem as well:
In the pkg file, add "RW" (Run Wait) to the flags of the installation script (just after the FILERUN and RUNINSTALL flags).
This makes the installer wait until the script exits. Therefore the sis file remains on the machine throughout the script's life time, eliminating the race condition.