Constanze Kratel, Community Program Manager bei Microsoft in Redmond interviewt Device Application Development MVPs. Den Anfang macht Sie mit Maarten Struys, MVP aus den Niederlanden. Dabei erzählt Maarten nicht nur über sich selbst, sondern teilt seine Gedanken über Mobility mit.

Definitiv sehenswert, alleine schon um die Personen auch mal zu sehen, die man sonst nur im Webcast hört.

- English Version -

Constanze Kratel, Community Program Manager at Microsoft in Redmond interviews Device Application Development MVPs. She starts with Maarten Struys, MVP from the netherlands. Maarten doesn't just talk about himself, but shares his thoughts.

A must see, already because you get to see people you normally just hear on a webcast.

Jason Langridge weißt daraufhin, dass eine Broschüre veröffentlicht wurde, welche herausstellt, wieso Windows Mobile eine grossartige Plattform für den Einsatz in Organisationen ist.

Die Broschüre im PDF Format kann hier heruntergeladen werden.

- English Version -

Jason Langridge points out, that an executive guide on Windows Mobile for Technical Decision Makers has been released. It outlines, why Windows Mobile is a great platform for Organisations to deploy.

The Executive Guide is available in PDF format here.

Alex Feinman wies mich gestern darauf hin, dass es anscheinend beim Erstellen von CAB Dateien mit lokalisierten Ressourcen unter Visual Studio 2008 zu einem Fehler kommt. Dies konnte ich selbst nachstellen.

Eine Variante zur Reproduktion:

1. Erstellen einer Geräteanwendung als C# oder VB.NET project
2. Hinzufügen einer neuen Ressource "Resource.en-US.resx"
3. Hinzufügen einer neuen Ressource "Resource.zh-TW.resx"
4. Hinzufügen einiger Strings zu den Ressource-Dateien
5. Erstellen des Projektes. Beachten Sie dabei, dass die entspr. erstellten Ressource-Dateien in den Unterordnern en-US and zh-TW abgelegt werden-
6. Hinzufügen eines CAB-Projektes für intelligente Geräte zur Projektmappe.
7. Hinzufügen der Projektausgabe/Primäre Ausgabe
8. Hinzufügen der Projektausgabe/Lokalisierte Ressourcen
9. Erstellen der CAB Datei. Installieren auf einem mobilen Gerät, wonach die installierten Resource-DLLs vom Zielverzeichnis des Gerätes auf die Desktop Machine kopiert werden.
10. Analysieren der DLLs mit ILDASM auf die MANIFEST/.locale. Alternativ: Reflector

Ergebnis:

Beide Ressource-DLLs sind identisch. Im konkreten Fall sind beide Dateien die der Sprache zh-TW.

Durch weitere Recherche stellte sich heraus, dass es sich hierbei um einen bereits bekannten Bug im CAB Wizard handelt. Somit geschieht dieser Fehler bei der manuellen Erstellung einer CAB Datei, als auch im Visual Studio.

Ilya Tumanov beschreibt hier hierzu einen Workaround:

...

Here's a workaround:

1. In main project which produces resource files run a post build procedure
which would create copies of these files with unique name.

For example, "fr\CONVENO Sales.resources.dll" would be copied to
fr\fr_CONVENO Sales.resources.dll

2. In your CAB project add files with unique names instead of originals.

3. Select these files one by one, choose "Rename" in context menu and type
original name.

Here's sample INF. Note files are unique now, but original names would be
restored on device.

Also note I've added files to "Application folder" so %InstallDir% macro is
actually used.

This macro can be redirected to storage card upon installation.

[Version]
Signature="$Windows NT$"
Provider="Microsoft"
CESignature="$Windows CE$"

[CEStrings]
AppName="PPC_CAB_1"
InstallDir=%CE1%\%AppName%

[Strings]
Manufacturer="Microsoft"

[CEDevice]
VersionMin=4.0
VersionMax=5.99
BuildMax=0xE0000000

[DefaultInstall]
CEShortcuts=Shortcuts
AddReg=RegKeys
CopyFiles=Files.Common1,Files.Common2,Files.Common3

[SourceDisksNames]
1=,"Common1",,"C:\Projects\LVTest\LVTest\bin\Debug\Fr\"
2=,"Common2",,"C:\Projects\LVTest\LVTest\bin\Debug\"
3=,"Common3",,"C:\Projects\LVTest\LVTest\bin\Debug\Gr\"

[SourceDisksFiles]
"fr_test.txt"=1
"LVTest.exe"=2
"gr_test.txt"=3

[DestinationDirs]
Shortcuts=0,%CE2%\Start Menu
Files.Common1=0,"%InstallDir%\Fr"
Files.Common2=0,"%InstallDir%"
Files.Common3=0,"%InstallDir%\Gr"

[Files.Common1]
"test.txt","fr_test.txt",,0

[Files.Common2]
"LVTest.exe","LVTest.exe",,0

[Files.Common3]
"test.txt","gr_test.txt",,0

[Shortcuts]

[RegKeys]

--
Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.

...

Andere Alternative: WinCE CAB Manager von ocpSoftware.

Angeblich ist dieser Bug schon länger bekannt, doch ein Fix ist seitens MS nicht in Sicht.

Danke Alex und Ilya, für die Information.

- English Version -

Alex Feinman informend me, that on creating CAB files including localized ressources under Visual Studio 2008 it can come to an error. I've been able to reproduce this behaviour.

One way of Reproduction:

1. Create a Form-based SmartDevice C# or VB.NET project
2. Add a new resource called Resource.en-US.resx
3. Add a new resource called Resource.zh-TW.resx
4. Add some strings to the resource files
5. Build the project. Observe that the resource DLLs are correctly
generated and placed into subdirectories en-US and zh-TW
6. Add a SmartCab deployment project to the solution.
7. Add Project Output/Primary Output
8. Add project Output/Localized Resource Assemblies
9. Build the cab file. Install it on the device and copy the resource
DLLs from the device install directory to the desktop machine.
10. Examine the DLLs with ILDASM tool checking MANIFEST/.locale. Or use Reflector.

Result:

Both resource DLLs are identical. In this case both are from the language zh-TW.

Trough further investigation it turned out, that this is a well known bug within the CAB Wizard. Therefore this bug affect manual building CAB files as well as building them from inside Visual Studio.

Ilya Tumanov describes here a Workaround:

...

Here's a workaround:

1. In main project which produces resource files run a post build procedure
which would create copies of these files with unique name.

For example, "fr\CONVENO Sales.resources.dll" would be copied to
fr\fr_CONVENO Sales.resources.dll

2. In your CAB project add files with unique names instead of originals.

3. Select these files one by one, choose "Rename" in context menu and type
original name.

Here's sample INF. Note files are unique now, but original names would be
restored on device.

Also note I've added files to "Application folder" so %InstallDir% macro is
actually used.

This macro can be redirected to storage card upon installation.

[Version]
Signature="$Windows NT$"
Provider="Microsoft"
CESignature="$Windows CE$"

[CEStrings]
AppName="PPC_CAB_1"
InstallDir=%CE1%\%AppName%

[Strings]
Manufacturer="Microsoft"

[CEDevice]
VersionMin=4.0
VersionMax=5.99
BuildMax=0xE0000000

[DefaultInstall]
CEShortcuts=Shortcuts
AddReg=RegKeys
CopyFiles=Files.Common1,Files.Common2,Files.Common3

[SourceDisksNames]
1=,"Common1",,"C:\Projects\LVTest\LVTest\bin\Debug\Fr\"
2=,"Common2",,"C:\Projects\LVTest\LVTest\bin\Debug\"
3=,"Common3",,"C:\Projects\LVTest\LVTest\bin\Debug\Gr\"

[SourceDisksFiles]
"fr_test.txt"=1
"LVTest.exe"=2
"gr_test.txt"=3

[DestinationDirs]
Shortcuts=0,%CE2%\Start Menu
Files.Common1=0,"%InstallDir%\Fr"
Files.Common2=0,"%InstallDir%"
Files.Common3=0,"%InstallDir%\Gr"

[Files.Common1]
"test.txt","fr_test.txt",,0

[Files.Common2]
"LVTest.exe","LVTest.exe",,0

[Files.Common3]
"test.txt","gr_test.txt",,0

[Shortcuts]

[RegKeys]

--
Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.

...

Alternative: WinCE CAB Manager von ocpSoftware.

This bug is said to be known for a longer period of time but no fix from MS it to be seen on this.

Thanks Alex and Ilya for this information.

Der RSS Feed dieser Seite kann nun auch über http://feeds.feedburner.com/PeterNowak. Bitte verwenden Sie diese URL ab jetzt nach Möglichkeit bitte primär.

- English Version -

The RSS Feed of this site has been changed to http://feeds.feedburner.com/PeterNowak. Please use this URL primarily, if possible.

Wer einige weitere und detaillierte Informationen zu meinem Artikel "Warum haben die nicht...?" / "Why didn't they...?" haben möchte, dem empfehle ich auf jeden Fall den englischsprachigen Artikel The Windows Mobile Ecosystem for Developers im The Windows Mobile RSS (Reed and Steve Stuff) Feed zu lesen. Hier erfährt man hintergründiges vieles, was selbst ich noch nicht wusste.

- English Version -

Who wants to get more detailed according to my article "Warum haben die nicht...?" / "Why didn't they...?", should read definitly the english article The Windows Mobile Ecosystem for Developers on the The Windows Mobile RSS (Reed and Steve Stuff) Feed blog. Here you get additional background information, which I didn't even know yet.

Als günstige Alternative zur Positionsbestimmung lässt sich anstatt GPS die Position auch mittels Triangulation der Mobilfunkmasten bestimmen. Hierfür benötigt man u.a. die CellID - also die eindeutige Kennung des Mubilfunkmastes.

Dale Lane zeigt in seinem Blog, wie sich man diese Information programmatisch aus seiner verwalteten Anwendung via P/Invoke abfragen kann. Hierzu verwendet er als Schnittstelle den Radio Interface Layer (RIL). Offiziell wird die RIL jedoch nicht von Windows Mobile unterstützt, weswegen man mit der API vorsichtig umgehen sollte.

- English Version -

As a cheap alternative for retrieving your position, you can use instead of GPS a triangulation of your cell towers. Therefore you need the CellID - a unique identifier of the cell tower.

Dale Lane shows in his blog, how to request this info programatically from your managed application via P/Invoke. Therefore he uses the interface to the Radio Interface Layer (RIL). Officially RIL isn't supported by Windows Mobile, so you should be very carefull working with this API.

Nach langer Abstinenz freue ich mich Ihnen mitteilen zu können, dass ich dieses Jahr wieder an der BASTA! teilnehmen werde, jedoch leider ohne einen Vortrag zum Thema Mobility.

Zusammen mit meinem guten Freund und Kollegen Simon Hackfort halten wir stattdessen ein nicht minder spannenden Vortrag zum Thema:

iTextSharp - PDF Generierung mittels .NET

Wer ein wenig über diesen Titel nachdenkt, wird auch hier einen Nutzen im Mobility Bereich feststellen.

Wann: 23.September 2008 um 15:15 Uhr

Abstract: Finalisierte Dokumente lassen sich nach wie vor am Einfachsten im PDF Format zur Verfügung stellen. Wie dies mit Hilfe der freien iTextSharp-Bibliothek realisiert werden kann, und welche Funktionen Ihnen hierzu zur Verfügung stehen, erfahren Sie in dieser Session.

Vor Ort werden Simon und ich vom 23.09. bis 25.09. sein. Wir freuen uns jetzt schon auf interessante Gespräche zwischen den Sessions, insbesondere sehr gerne über den Bereich Mobility.

Da gerade Mobility mein Hauptthema ist, verweise ich Sie gerne auf den .NET Mobile Day, welcher Teil der BASTA! sein wird. Nähere Informationen hierzu erhalten Sie hier von Torsten selbst.

Die BASTA! 2008 selbst findet vom 22. - 26. September in der Rheingoldhalle in Mainz statt. Alle weiteren Informationen zur Veranstaltung finden Sie hier.

- English Version -

For a few years I haven't made it to the BASTA! Conference. This year I'm glad to announce that I'm part of it again, unfortunatly without a session on Mobility.

My good friend and colleague  Simon Hackfort will present a session, which won't be less interesting:

iTextSharp - Generating PDF documents via .NET

Whoever thinks a second about that topic will discover probably a relation to Mobility as well.

When: September 23rd 2008 at 3:15 PM

Simon und I will be there from September 23rd to 25th. We are already excited about all the interesting talks we will have between the sessions, especially on Mobile topics.

As Mobility is my main topic I'd like to refer to the .NET Mobile Day, which will be part of the BASTA!. Further information on this can be found from Torsten here .

BASTA! 2008 will take place from September 22nd to 26th in the "Rheingoldhalle" in Mainz. Additional information about ths event can be found here.

Torsten hat es bereits verkündet und gibt ein paar Informationen, wieso das letzte Buch nichts wurde und wie es weitergeht...

Lest es hier selbst.

- English Version -

Torsten already has announced the following book and gives a few infos, why the last one didn't happen and how it will go on...

Read on here.

Es gibt etwas, was mich schon lange nervt. Mindestens 2 mal täglich höre ich Fragen, wie "Warum hat Microsoft das nicht direkt eingebaut" hinsichtlich vorhandenen Funktionalität im .NET Compact Framework oder dem Windows Mobile SDK für verwalteten Code. Das eine oder andere Mal kann ich der Frage zustimmen, aber generell nervt diese Frage nur noch.

Andererseits - Ich stellte mir diese Frage bereits selbst einige Male in der Vergangenheit. Doch ich bekam einige Antworten hierzu, die ich gerne mit diesem Post mit Ihnen teilen möchte. Ich hoffe, dass die Frage somit eher zu einer rhetorischen Frage verkommt. Versuchen wir also hier die Antworten zu finden und schauen ein kleinen wenig hinter die Kulissen.

Jede neue Version, sei es nun vom Compact Framework oder dem Windows Mobile SDK hat natürlich ein kleineres Budget, verglichen mit Windows oder Office.

Dabei sollte man bedenke, dass das Budget nicht nur die Entwicklung neuer Funktionalität bedeutet, sondern auch das Fixen von Bugs, da Sie ja selbst wissen, dass keine Software frei von Bugs sein kann. Die führt natürlich auch dazu, dass manche neuen Funktionen oder vielleicht geringere Bugs auch auf andere Versionen verschoben werden müssen, da einige Bugs oder Funktionen höher priorisiert sind, als andere. Dabei geschieht die Priorisierung seitens "des Kunden". Je öfter Anfragen zu einem Bug oder einer Funktion gestellt werden, umso höher ist auch die Priorität für die folgende Version.

Weiterhin ist eine neue Version des Compact Frameworks oder des Windows Mobile SDKs nicht anderes als jedes Projekt, welches Sie selbst realisieren. Sie haben einen Zeitplan mit einem definierten Release Datum, welches es gilt einzuhalten. Die führt oftmals auch zu einer Kürzung der Liste neuer Funktionen.

Windows Mobile basiert ja, wie Sie wissen, auf Windows Embedded CE. Dies bedeutet im Umkehrschluss, dass (oftmals) Funktionalität nicht unterstützt werden kann, wenn Si e nicht bereits in der Basis enthalten ist. Dies führt zu einer Abhängigkeit im Projekt, welche ebenfalls beachtet werden muss.

Aber es gibt eine weitere Abhängigkeit: Was bringt Ihnen die neueste Funktionalität, wenn Sie nicht von zugehörigen Tools, wie dem Visual Studio oder Windows Mobile beispielsweise selbst unterstützt wird?

Selbst Produkte, welche man eher nicht vermuten würde (Office, Windows) haben selbst, wenn auch einen kleinen Einfluss auf die Planung.

Wenn Sie dies alles einmal zusammengefasst betrachten, dann erkennen Sie, dass eine derartige Planung bereits sehr komplex wird.

Hinzu kommen aber noch andere Gesichtspunkt. Wussten Sie beispielsweise, dass es auch eine festgelegte Beschränkung hinsichtlich einer neuen Version des Compact Fameworks oder des Windows Mobile SDKs gibt, welche nicht überschritten werden darf? Auch das kann dazu führen, dass beriets vorhanden Funktionalität einer Betaversion wieder in der finalen Version entfernt wird. Der Grund hierfür liegt darin, dass das Framework entsprechend auch im ROM des Betriebssystems abgelegt werden soll/muss, wo Speicher eher rar gesät ist.

So kann es aber auch passieren, dass erst während der Entwicklung erkannt wird, dass eine neue Funktionalität das System beispielsweise verlangsamt und somit möglicherweise ein höherer nicht kalkulierter Entwicklungs- oder Testaufwand nötig ist (gerade bei der Portierung von vorhandener .NET Framework Funktionalität).

Nehmen Sie nun einmal alles zusammen und Sie erkennen, dass dieser Job nicht wirklich einfach ist.

Jetzt, wo Sie wissen, was u.a. alles beachtet werden muss (und ich wette, dass meine Aufzählung längst nicht vollständig ist, da ich selbst keinen vollen Einblick erhalte), stellt mir sich die Frage, ob Sie die eingangs gestellte Frage immer noch so oft werden wollen.

Als kleine Anmerkung meinerseits: Es gibt sehr viele Personen, die versuchen ihr Bestes die gewünschte Funktionalität aus eigenem Antrieb in ihrer Freizeit (meist ohne einen finanziellen Hintergrund) zur Verfügung zu stellen. Aus diesem Grunde erwähne ich an dieser Stelle herzlichst gerne noch einmal das Smart Device Framework von OpenNETCF, welches hierfür ein sehr gutes Beispiel ist.

Ich hoffe, dass ich Ihnen hiermit eine befriedigende Antwort geben konnte. Vielleicht konnte ich Sie sogar dazu motivieren ihr eigenes Projekt zu beginnen, um fehlende Funktionalität zu entwickeln und diese auf CodePlex oder woanders zur Verfügung zu stellen?

P.S.: Dieser Post sollte neutral gemeint sein. Es soll weder pro noch contra Microsoft, deren Produktgruppen oder sonst noch in diesen Prozess involvierten Personen sein. Nehmen Sie diese Informationen bitte so hin, wie Sie dort stehen.

Sollten Sie an einer weiteren Sichtweise interessiert sein, so empfehle ich Ihnen diesen post vom Windows Mobile Team.

- English Version -

It is playing on my nerves. At least I hear twice a day the question “Why didn’t Microsoft include it directly”, talking about unsupported functionality in the Compact Framework and Windows Mobile SDK for managed Code. Sometimes I have to agree, but most of the time this question becomes really annoying.

On the other hand – I’ve asked myself this question several times in the past, but finally could get some answers, which I want to share with this post. I hope this turns the question more into a rhetoric question. Let’s try to find some answers and take a small look behind the scenes.

Each new version, whether for the Compact Framework or the Windows Mobile SDK has naturally a smaller funding compared to Windows or Office.

You have to keep in mind, that the funding doesn't cover only new features, but as well bugfixing, as you know that no software is free of bugs. This leads to the point that some functionality or bugs have to be postponed on the list for a later version, as some bugs and features are higher priorized as others.

The priorization therefore is mostly driven by customer requests. The more customers request a new feature or complain about a bug the more it is likely to be included within the next version.

On the other hand a new version of the Compact Framework or Windows Mobile SDK is nothing else than any project you do – you have a time schedule, which has a defined end date. This shortens the list of new functionality as well.

As you know, Windows Mobile is based on Windows Embedded CE. This means in reverse, that (often) functionality can’t be supported, if it isn’t supported by the base system. This causes a dependency, which has to be considered for new functionality as well. It is very uncommon to offer hardware-dependent functionality not offered by the base system.

But there is another dependency as well: What do you want to have the newest functionality for, if it isn’t supported by additional Tools or the Visual Studio or by Windows Mobile itself?

Even Products you don't expect directly connected to Mobility (Office, Windows) themselves can even have (a really small) influence on the schedule and planning.

Taking these points in consideration you already see, that it becomes very complex here. But there is more. Did you know for example, that each new version of the .NET Compact Framework has a limitation in memory size, which can not be extended? This leads to the point that sometimes already included functionality has to be excluded again. The limitation is given, because the Compact Framework f.e. has to fit into the ROM Image for Windows Mobile or Windows Embedded CE. This limits functionality or changes priorization in functionality as well.

It can happen during development, that new functionality turns out to slow down the system, or takes more time to be developed, optimized or tested (especially, if porting desktop functionality) which itself has an influence why things tend to be like they are.

Taking all these points into account, you can see the job becoming very hard.

Now that you know, what is taken into consideration (and I bet my summary isn’t complete here, as I don’t have a full insight) are you going to ask the mentioned question as often as you do?

Just as a short note: There are enough people out there, which try to give you the functionality you want and spend their free time for this (sometimes without funding) and do their best they can. I very like to mention the Smart Device Framework by OpenNETCF, which is a very good example for this.

I hope I could give you a satisfying answer to your question. Probably you are now even motivated to start your own project to offer yet missing functionality on CodePlex or elsewhere?

P.S.: This post is meant to be neutral. It is not meant to be pro or contra Microsoft, Product Groups or anyone else included into this process. Just take this info I give you here as is.

If you are interested in another view, I recommend reading this post from the Windows Mobile Team.