CeAppMgr fails either due to a long string or a CAB differentiatio

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi!!!!!

I'm using the CeAppMgr to deploy my Application, and I'm having a
problem with my Setup.Ini file. It seems that either:

* The "CabFiles" line can only have up to certain number of characters (or
cab files), or
* The CeAppMgr is failing to differenciate between some cabs.

Let me give you more details: I created an application using VB.NET
2003 for Windows CE and Pocket PC. When I compile the application, it
automatically creates 14 cab files, one for each kind of processor &
operating system. This application that I create works well in both platforms
(WinCE and PPC).

When I put the list of all the CABs that were created in the Setup.ini,
CEAppMgr fails saying that the setup.ini file is invalid. HOWEVER, if I take
out half of the cab file list, CEAppMgr works perfectly fine. It doesn't
matter which half I take out, it works.

This made me think that having too many files in the CabFile line may
overflow the CEAppMgr (which I hope I'm wrong because being able to
distribute between many kind of devices is a must), or there is a cab that
works for both WinCE & PPC (which I don't think it is the case since
otherwise VB.Net wouldn't have created two of them).

Any help is greatelly appreciated!!!!

Tark ik
 
Yes, there's a limit on string size listing CAB files (255 charters or so).
If exceeded, CEAppMgr.exe will complain, which is what you observe.

Also, for CEAppMgr.exe to recognize which CAB to deploy, the INI file, used
to create these CABs, should have both version and ProcessorType correctly
set for each supported CPU/Platform:

[CEDevice]
ProcessorType = 10003
VersionMin = 4.000
VersionMax = 4.999

If not set, CEAppMgr.exe will grab the first CAB from the list (which is
another thing you probably observe).

Now, what to do about it...

If your application does not have any native components (including setup
DLL in the CAB), you only need one platform independent CAB.

If that's not the case, you might be able to limit the number of supported
platforms.

For example, general purpose applications (e.g. games) can be safely
limited to Pocket PC platform only.
It's very unlikely somebody would run a game on MIPS II based industrial
controller with Windows CE, right?

Now, PPC 2000 is 5+ years old which is beyond reasonable life span (dead
battery, crazy digitizer, lost/broken/stolen etc.).
That leaves PPC 2002 (also just one step away from been recycled) and PPC
2003, which is a current platform.
That means you can go with just one ARM CAB and yet cover 95% (probably,
more) of all outstanding devices.

If your application is a "made to order" one, its target platform is
probably set for years to come by your customer.
So just do a deployment for it.

Finally, if it's all not acceptable, you can implement custom deployment.
Please see this:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetcomp/h
tml/netcfdepl.asp

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
 
Thanks Ilya!!!

Your suggestions make sense to me. My application targets industrial
devices, and you're right: I should expect that many handhelds have died in
the line of dutty, specially in this environment (hehehehe). Focusing in the
newest devices should be the path to follow.

I'll see if reducing the name of the cab files might help as well.

Best Regards,

Tarh ik
 
Back
Top