klaus_b@.NET

Wer Microsoft Outlook® verwendet und mehrere Rechner besitzt, kennt das Dilemma der unterschiedlichen Datenstände bestimmt ebenfalls sehr gut. Man ist mit dem Notebook unterwegs und hat den dringend benötigten Kontakt natürlich auf dem Desktop-PC. Oder kürzlich hat man eine interessante Person kennengelernt und will ihr eine Email schreiben, vom Desktop-PC aus. Die Kontaktdaten wurden natürlich schön sauber in Outlook eingetragen, aber auf dem Notebook.
Genau hier setzt das Produkt SYNCING.NET, der gleichnamigen Firma, an. Es verspricht die unterschiedlichen Outlook Datenbeständen auf verschiedenen Rechnern synchron zu halten; auch über das Internet.
Außer Outlook-Daten können auch beliebige andere Dateien auf verschiedenen Rechnern synchron gehalten werden. Einen ersten Überblick, was SYNCING.NET macht, kann man sich auf der Produktseite verschaffen.

Viel mehr als die Arbeitsweiße von SYNCING.NET, interessierte mich die Technik in der Software. Der Name SYNCING.NET suggeriert die Verwendung des .NET-Framework. Also interessierte mich brennend die Frage: ist auch .NET drin, wo .NET draufsteht?
Bevor ich irgendwelche Reverse Engineering Experimente veranstaltete, ging ich den einfacheren Weg: Ich fragte die Entwickler der Anwendung. Sie erteilten mir auch bereitwillig Auskunft.

Q: Wurde die Anwendung tatsächlich auf Basis des .NET-Framework entwickelt, wie der Name suggeriert?
A: SYNCING.NET basiert ursprünglich auf .NET Framework 1.1, wenn auch mit einer externen COM-Komponente. Der erste Prototyp von SYNCING.NET bestand lediglich aus zwei Einzelmodulen:
· GUI in C#.NET (managed Code)
· MAPI-Zugriffsmodul in Visual C++ (unmanaged Code; notwendig wegen MAPI-Zugriff)

In der heutigen Fassung besteht SYNCING.NET aus drei Modulgruppen:
· Applikationskern in C#.NET (managed Code)
· Outlook-Module in Visual C++ (unmanaged Code; notwendig wegen MAPI-Zugriff)
· Infrastruktur-Module in Visual C++ (unmanaged Code; historisch gewachsen, da ursprünglich eigenständige Software)

In der ursprünglichen Fassung musste die Infrastruktur noch durch ein externes Zusatzprogramm bereitgestellt werden; seit SYNCING.NET 2.0 verwenden wir jedoch eine eigene Modulgruppe für diesen Zweck.

Q: Wenn ja, auf Basis von Windows Forms oder schon WPF?
A: Der Applikationskern von SYNCING.NET (mitsamt GUI) verwendet das Windows Forms Widget Set.

Q: Wenn .NET in welcher Sprache, also C#, VB.NET oder managed C++?
A: Der Applikationskern von SYNCING.NET (mitsamt GUI) wurde und wird in reinem C# entwickelt; diese Sprache wird von uns als ideale Sprache für die Entwicklung in .NET angesehen. C++ musste als Sprache beispielsweise extra angepasst (bzw. in seinen Möglichkeiten beschnitten) werden um als „managed C++“ .NET-kompatibel zu sein; VB.NET hingegen ist wie seinerzeit schon VB einfach nicht mächtig genug für die professionelle Entwicklung.

Q: Wenn die Anwendung nicht auf .NET basiert, ist auch eine 64bit Variante erhältlich? Diese ist ein Punkt, der heute immer mehr Anwender interessiert.
A: Eine echte 64-Bit-Umsetzung ist bei unseren Outlook- und Infrastrukturmodulen bereits umgesetzt worden wodurch auf 64-Bit-Windows-Systemen auch die Verarbeitung spürbar schneller ist als auf 32-Bit basierten; lediglich unser Applikationskern inklusive GUI wird weiterhin im 32-Bit-Modus ausgeführt, da hier eine messbare Beschleunigung der Verarbeitungsgeschwindigkeit in keiner Relation zum Aufwand eines 64-Bit-basierenden Redesign stehen würde.

Mir persönlich gefallen an den Antworten der Entwickler besonders drei Dinge:
· Die Anwendung basiert tatsächlich auf dem .NET-Framework.
· C# scheint die bevorzugte .NET Sprache zu sein.
· Auch Entwickler kommerziellere Software verwenden gerne Module aus unmanaged Code.

Zusätzlich zu einer Software die nun endlich Ordnung in mein Outlook Chaos bringt, wurde ich auch in meiner Entscheidung bekräftigt, weiterhin auf das .NET-Framework als Entwicklungsplattform zu setzen.

Wenn ihnen der Artikel gefallen hat oder er für sie hilfreich war, bitten "kicken" sie ihn.