I am still struggling with the first steps in programming with carbide C++ for S60 3rd edition. I understand that an application must be signed to be installed on a device. The pdf file found in the SDK docs s60_3_0_how_to_sign_sis_files_1_4.pdf is somewhat helpful but I have two questions at this point:
1. build with configuration S60 3.0 Phone(GCCE) Release produces a sis file; should I try to keep that sis file when using createsis? Can createsis work without a build? I am quite confused here as you can see...
2. Does Carbide C++ provide an option or an interface to facilitate the self-signing process? Or the only way is command line?
Well, I guess I can answer my questions now since I have a done a little more of homework... In Carbide C++, in Project/ Properties / c/c++Build there is a sections CreateSis. Now looking at the docs it looks like the self-signing process is done automatically by default. When I install the app on my E70, I am getting a 'Certificate Error, contact the application supplier".
There is one small "gotcha" here and that is the application UID.
IF you create an application with the Carbide.c++ application wizard, the wizard will by default assign a UID in what is called the protected range. This UID range is not compatible with the default selfsigning certificate. If you import, you need to check the UID a choose an appropriate certificate based on the UID in the imported app.
So, to succesfully autosign an application in Carbide.c++ when you start with a new project:
- Before creating your application, make sure you understand whether you need a protected or unprotected range UID for your application
- Do one of the following:
1) In the New application wizard, modify the proposed UID to one that resides in the unprotected range (0xE..), in this case you can sign with the default selfsign certificate.
2) Use the proposed default UID but change the signsis certificate setting so that signing uses a developer certificate that you have obtained from Symbian.
In both cases, provided you have a (correct) .pkg file in you project, the GCCE build will automagically produce a .sis file that should nicely install on your phone. No need to use the command line for any of this!
Thanks a lot it; that was the problem. I also took the unprotected UID I got from the symbiansigned website and it worked fine. Great!
The other thing I had to do is on my Nokia E70 go to Menu / Tools / AppMgr / Settings / Installation and check "All" instead of "Signed Only". Looks like that "Signed Only" excludes self-signed application.
To follow up on Jim's post, do you think it is worth using the Symbian\9.1\ S60_3rd_MR, the 3rd edition Maintenance Release?
Thanks again for your help
I dont know why people download version of s60 3rd, especially as old version will not compile HelloWorldBasic.
It cannot be because the pointer on the "sticky"
"Carbide.c++ Express available for download"
because the link does link to anything http://www.forum.nokia.com/main/0,,034-1001,00.html
comes back "page not found"
I know that it in my case I downloaded the 3rd Edition and not the MR version because at the end of the installation of Carbide C++, the file
automatically opens. This file lists links to the the SDKs as well as a link to ActivePerl-126.96.36.1995. The S60 3rd Edition link points to: http://ncsp.forum.nokia.com/download...0-f.3.215f.zip
which is not the maintenance release version. The maintenance release is not mentioned anywhere.
The current SDK Support in Carbide.c++ file
also shows that we need to install ActivePerl-188.8.131.525.
I had already Perl 5.8 on my system and it was unclear to me if I should get the 5.6.635 version or the most recent version 5.8 was ok. I could not exclude the case where Nokia wanted 5.6.635. So maybe clarify that point.
ActiveState is exactly that, very "active" and do a very good job in updating their software quite often in response to customer feedback etc. Due to that it is next to impossible for Nokia to absolutely track the Perl version.
When we put out a product, we put as supported the version that was current when we tested. A developer who installs later often will find the supported version superceded by a newer one. Lately newer versions have not caused any grief so that is the way to go. However I suggest you stay with the 5.6 line, the 5.8 line has been known to cause some issues due to different behaviour in some cases.