Hi,
another question regarding the signing requirement for embedded SIS
files: does this also apply to such packages that cannot be
independently tested, because they do not contain a runnable application?
For example, if my project uses a SIS file that contains only DLLs, or a
server EXE with no UI, how can I get get these signed? Would that be a
"passive content"-signing step that has to be performed each time before
the enclosing application can be submitted for testing?
In case anybody wonders "why bother with embedded SIS files": these are
shared components that will be used by more than one application, and
since shared DLLs don't have their own reference counts in Symbian,
wrapping them into a SIS seems to be the only option to make sure they
stay arond until the last client using them is uninstalled.
ciao marcus
"Marcus Groeber" <[email protected]> wrote in message news:FPNWvoj6FHA.1036@extapps30...
> Hi,
>
> another question regarding the signing requirement for embedded SIS
> files: does this also apply to such packages that cannot be
> independently tested, because they do not contain a runnable application?
You can provide a full options test application with the package.
> For example, if my project uses a SIS file that contains only DLLs, or a
> server EXE with no UI, how can I get get these signed? Would that be a
> "passive content"-signing step that has to be performed each time before
> the enclosing application can be submitted for testing?
Your dlls may be anything you want but not "passive content" ... unless you do like to save .jpg images with .dll extension 😊
> In case anybody wonders "why bother with embedded SIS files": these are
> shared components that will be used by more than one application, and
> since shared DLLs don't have their own reference counts in Symbian,
> wrapping them into a SIS seems to be the only option to make sure they
> stay arond until the last client using them is uninstalled.
True. Another reason is that this way you can keep track of your engine's version and make sure that even if the latest installed client application contains an older engine version it will not replace the already existing one.
> ciao marcus
Ciao,
Lasse
Lasse wrote:
[color=green]
> > another question regarding the signing requirement for embedded SIS
> > files: does this also apply to such packages that cannot be
> > independently tested, because they do not contain a runnable application?
> You can provide a full options test application with the package.[/color]
I know that I *can*, but the question is more whether I *must*. 😊
Also, would this test application have to be included in the package to
be signed, so the end-user sees it as well?
Simply because I choose to group my DLLs in a different way inside the
package that the user installs, does this force we to write this
additional test code, and to go through a separate testing cycle (which
realistically would add another week elapsed or so to the timeline of a
release, since I first have to get the DLL tested and signed, and only
then can build the final package of the overall application for testing)?
ciao marcus
There is now way, I think, Symbian Signed will accept to sign code that is
not tested. If you do not have a test application then you probably have a
client who has a application that will fully use you engine package. Why not
use that application for testing ...
The test application does not have to be include in the package ... if you
do not want to. Just provide it to the test house and explain what they
should do with it ... You should also discuss with them about the test
criteria. For example I do not think that the low memory startup test has
any value in your case as it is your client's job to make sure that it
behaves right in those conditions, even if that implies not loading your
engine ...
Best regards,
Lasse
"Marcus Groeber" <[email protected]> wrote in message
news:JPXz5J16FHA.1008@extapps30...
> Lasse wrote:
>[color=green][color=darkred]
> > > another question regarding the signing requirement for embedded SIS
> > > files: does this also apply to such packages that cannot be
> > > independently tested, because they do not contain a runnable[/color][/color]
application?[color=green]
> > You can provide a full options test application with the package.
>
> I know that I *can*, but the question is more whether I *must*. 😊
> Also, would this test application have to be included in the package to
> be signed, so the end-user sees it as well?
>
> Simply because I choose to group my DLLs in a different way inside the
> package that the user installs, does this force we to write this
> additional test code, and to go through a separate testing cycle (which
> realistically would add another week elapsed or so to the timeline of a
> release, since I first have to get the DLL tested and signed, and only
> then can build the final package of the overall application for testing)?
>
> ciao marcus[/color]