Will man in einem Programm sensible Informationen wie z.B. Passwörter schützen so sollte man diese beim Speichern nach Möglichkeit verschlüsseln. Um zu verhindern, dass fremde beim Zugriff auf den PC einfach die Daten kopieren und auf einem anderen PC entschlüsseln können gibt es seit Windows XP die DPAPI (Data Protection API) welche Daten so verschlüsseln kann, dass man diese nur entweder auf dem gleichen PC oder nur mit dem gleichen Benutzeraccount wieder entschlüsseln kann.

Für diese native API gibt es im .NET Framework eine Wrapperklasse mit dem Namen ProtectedData welche sich im System.Security.Cryptography-Namespace befindet. Dazu muss allerdings vorher das Assembly System.Security.dll eingebunden werden. Im folgenden ein kleines Beispiel:

Bei portablen Anwendungen welche auf mehreren Rechnern ausgeführt- und die gleichen Settings verwenden sollen würde ich allerdings auf eine andere Methode setzen, sonst führt das unweigerlich zu Problemen.

Seit Windows 7 gibt es die sogenannten Jumplists, welche über einen Rechtsklick auf das Programmicon in der Tastbar erreicht werden können und Zugriff auf zum Beispiel oft genutzte Funktionen oder zuletzt geöffnet Dateien bieten.

Wirklich genutzt wird diese neue Funktion derzeit noch von wenigen Programmen. Hier kommt nun der kostenlose Jumplist Extender (alternativer Downloadlink) zum Einsatz: Dieser bietet die Möglichkeit die Jumplists beliebiger Programme zu manipulieren. So kann ich z.B. meinen Musikplayer XMPlay einen Jumplisteintrag zu meiner Lieblingsplaylist hinzufügen um diese mit wenigen Klicks erreichen zu können.

Neben beliebigen Dateien lassen sich auch Ordner öffnen, Tastenkombinationen an das geöffnete Programm senden sowie AutoHotkey-Scripte ausführen, für welche es sogar einen integrierten Editor gibt. [via]

Auch wenn derzeit etwas langsam, aber die Entwicklung vom updateSystem.NET geht voran. Aus diesem Grund möchte ich euch ein paar Einblicke geben, was es in dem demnächst erscheinendem Minorrelease so an neuen bzw. erweiterten Funktionen geben wird.

Ich habe beim Release der Version 1.0 einiges an Feedback bekommen. Aufgefalllen ist, dass einige mit dem neuen System der updateActions leicht überfordert waren. Deshalb werde ich zum einen mich hinter die Schnellstarttutorials klemmen und zum anderen wird es einen Assistenten geben welcher einen durch die meist genutzten Aktionen führt (Prozesse beenden –> Dateien kopieren –> Prozesse starten) und so den Umgang erleichtert. Nach Abschluß des Assistenten erscheint dann der normale Dialog zum bearbeiten eines Updatespaketes in welchem dann weitere Änderungen vorgenommen werden können.

Man soll es mit Assistenten zwar nicht übertreiben, aber einen wird es (wieder) geben. Und zwar den smartPackage Wizard, welcher bereits erstellte Updatepakete analysiert und daraus ein neues Paket generiert. Für Leute die die Updatepakete nicht über die Kommandozeile generieren ist es doch schon etwas nervig für jedes Update die gleichen Aktionen erstellen zu müssen wenn sich z.B. nur eine Datei geändert hat. Dort schafft dann das smartPackage abhilfe.

Desweiteren habe Ich irgendwie das Gefühl, dass ich die Änderungen pro Version etwas zu komplex aufgezogen habe. Prinzipiell würde doch auch ein simples Multiline-Textfeld pro Sprache die gleichen gestalterischen Möglichkeiten bieten wie die aktuelle Lösung. Nur nicht so umständlich. Da bin ich mir nur noch etwas unsicher. Mal sehen was mir dazu während der Entwicklung noch einfällt.

Für einen Releasetermin möchte ich mich eigentlich noch nicht festlegen, aber ich gehe davon aus das ich es noch vor meinem Geburtstag schaffe. Und noch was kleines in eigener Sache: Yay, dass war der 100te Beitrag :-)

Seit gestern ist es soweit, dass Visual Studio 2010 sowie das .NET Framework 4.0 wurden offiziell von Microsoft in der finalen Fassung freigegeben. Derzeit sind die beiden Produkte nur in der englischen Fassung verfügbar. Die lokalisierten Downloads sollen Ende April folgen.

Neu in dieser Produktfassung ist, dass die Produkteditionen überarbeitet wurden. So gibt es keine Standardedition mehr, sondern nur noch Professional, Premium und Ultimate. Weiterhin gibt es für Hobbyentwickler die kostenlosen Express Editionen für die Sprachen C#, C++, VB.NET und ASP.NET. Ein paar mehr Informationen über die Neuerungen habe ich bereits beim erscheinen des Release Candidates geschrieben.

Überrascht war ich heute etwas beim Lesen meiner Newsfeeds als ich über den offiziellen Blog von Paint.NET geschaut habe. Die neue Betaversion 3.5.5 von Paint.NET wurde schon mit dem neuen .NET Framework 4.0 kompilliert. Kann man nicht meckern, ziemlich flink der Entwickler. Zudem wird auf diese Weise das neue Framework schneller verteilt.

Quicklinks

• Visual Studio 2010 Testversionen (90 Tage Laufzeit)
• Visual Studio 2010 Express Editionen
• Microsoft .NET Framework 4.0

Heute bin ich durch Zufall auf einen Facebookclient gestoßen, welcher von den Microsoft uxLabs entwickelt wurde. Es nennt sich Fishbowl und wurde mit C# und WPF realisiert:

Gedacht war dieser Client wohl als Beispielprojekt für Microsofts Facebook SDK und demonstriert den Umgang damit (Quellcode von beidem findet man bei Codeplex). Vom Funktionsumfang her wurde so ziemlich alles Umgesetzt was man auch mittels Browser auf der Facebookseite erreichen kann. Allerdings werden Kontakte und Fotoalben optisch schick aufbereitet und dargestellt. Was etwas stört ist die etwas verschwomme Schrift welche leider typisch für WPF-Anwendungen ist.

Im Client verbaut ist auch eine Unterstützung von Windows 7 Features wie Jumplists, TaskBarPreviews uns IconOverlays mit z.B. der Anzahl neuer Events im Programsymbol der TaskBar.

Ich bin ja immer noch auf der Suche nach dem perfekten Musikplayer mit schnellem und brauchbarem Library welcher auch noch Ressourcensparend ist. Songbird ist zwar nicht schlecht und bietet einiges an bereits integrierten Funktionen und noch vieles mehr was man an Addons nachladen kann, aber die Geschwindigkeit (besonders beim Start) ist nicht das Wahre.

Mehr durch Zufall bin ich dann auf den ebenfalls kostenlosen Player MusicBee gestoßen. Funktionsmäßig steht dieser den Großen auf den ersten Blick in nichts nach.

MusicBee bietet eine schnelle und übersichtliche Musikbibliothek, einen umfangreichen Editor für Tags (fehlende oder unvollständige Tags lassen sich automatisch via Internet ergänzen) und noch vieles mehr. Der komplette Player basiert übrigens auf dem Microsoft .NET Framework 2.0, ein weiterer Pluspunkt, denn wer mich kennt wird wissen, dass ich .NET Software gern bevorzuge. Für die Web 2.0 Freunde gibt es auch die Möglichkeit die Tracks direkt an last.fm zu scrobbeln (der Sinn davon muss jetzt nicht nochmal diskutiert werden). MusicBee ist (zumindest die aktuelle Beta 1.2) mit Windows 7 kompatibel, das heißt, dass man in der TaskBar-Vorschau, wie aus dem Windows Media Player bekannt, die Buttons für Vor, Zurück und Play/Pause findet.

Ich habe hier nur die Funktionen erwähnt, die mir sofort aufgefallen sind bzw. welche mir für einen Musikplayer wichtig sind. Eine komplette Übersicht über alle Funktionen gibt es in Featureübersicht auf der MusicBee Website.

Fast schon drei Wochen ist es her, als ich nach einer langen Entwicklungszeit die Version 1.0 von meinem updateSystem.NET veröffentlicht habe. Seit dem wurde es mehr als 200 Mal heruntergeladen und circa 10 Leute öffnen pro Tag mindestens einmal den updateDesigner. Nicht schlecht, wie ich finde. Vor allem möchte ich mich aber für das durchweg nette und konstruktive Feedback bedanken, dass ich in der Zeit via Kommentar, E-Mail oder Foreneintrag erhalten habe. Sowas motiviert immer ungemein.

Aber wie geht es nun weiter?
Meine ToDo-Liste ist seit dem Release stetig gewachsen und kleinere sowie ein paar größere Änderungen habe ich schon implementiert. Morgen werde ich aller Voraussicht nach einen kurzen Entwicklungsstopp einlegen, das bereits implementierte testen und dann ein Update mit den Neuerungen herausbringen.
Neben ein paar kleineren kosmetischen Änderungen, gibt es in der kommenden Version die Möglichkeit die Dateien der Statistikserver über den updateDesigner zu aktualisieren (siehe Bild rechts).
Desweiteren habe ich die Schnittstelle für die Changelogplugins um eine zusätzliche Eigenschaft erweitert. Man kann nun den “Öffnen”-Dialog unterdrücken. Als (einziges) praktisches Beispiel was mir auf die schnelle einfällt, bei welchem man diese Option setzen könnte, ist der Import der Changelogdaten aus der Zwischenablage. Ich habe übrigens selbst ein entsprechenden Plugin für solch einen Import geschrieben, welches automatisch ab der nächsten Version mit dabei sein wird.

Und was wird die Zukunft bringen?
Für wirklich spätere Versionen, also 1.1 oder 1.2 habe ich ein paar größere Änderungen geplant. Diese betreffen in Erster Linie die updateActions. Dort im speziellen den Aufbau und die Verwaltung. Was mich persönlich am Updatesystem total stört ist der kleine Editor für die Updateactions. Hier möchte ich dringend nachbessern, allerdings ist mir noch keine brauchbare Lösung eingefallen, wie man Toolbox, Auflistung und den Editor platzsparend und einen Hut bringen kann. Momentan geistert mir eine “Ein-Form-Lösung” durch den Kopf, welche mittels Ribbons (s. neue Version vom assemblyCompressor) organisiert wird. Aber das ist alles noch nicht Spruchreif.

Tja, ich weiß ehrlichgesagt nicht, warum ich diese Anwendung geschrieben habe, vermutlich aus Langweile, weil heute nichts anderes so wirklich klappen wollte. Ich selber nutze kein Twitter (den Sinn davon habe ich noch nicht erschließen können), aber ich habe aber dennoch einen Account in welchem ich eigentlich nur über neue Blogposts informiere oder eben die API Teste. Wie dem auch sei, vielleicht gibt es den ein oder anderen der diese Anwendung gebrauchen kann.

Aber worum geht es denn überhaupt? Ich habe eine Anwendung geschrieben, die sich beim Start in den Systemtray einbettet und beim klick auf das Icon einen simplen Dialog zum eingeben der Nachricht anzeigt. Über einen Rechtsklick kann man die Optionen (Autostart, Benutzerdaten) ändern oder das Programm beenden.

Optisch integriert sich die Anwendung ganz gut in den neuen Traybereich von Windows 7. Lauffähig ist sie auch unter Vista und vermutlich auch unter XP.

Wer also nun Interesse hat, kann sich die Anwendung hier herunterladen: trayTwittr.exe.

Wer sich unter .NET schon mal zum Beispiel der Pluginentwicklung gewidmet hat, und dabei das Assembly welches das Interface enthält, das Host und Plugin zur Kommunikation nutzen, mit einem starken Namen signiert hat, wird sicherlich nach dem inkrementieren der Versionsnummer gemerkt haben, dass Plugins welche gegen eine niedrigeren Version der Interfaceassembly kompiliert wurden nicht mehr geladen werden können.

Grund dafür ist, dass die Common Language Runtime (CLR) wegen dem starken Namen der Interfaceassembly die genaue Referenz voraussetzt. Wird die Versionsnummer also verändert weicht der vollqualifizierte Name ab und die Assembly ist nicht mehr auffindbar.

Lösungen für dieses Problem gibt es nach meiner Recherche zweierlei.

Lösung 1: In der AssemblyInfo-Datei welche vom Visual Studio erstellt wird findet man zwei Angaben zur Versionsnummer. Die AssemblyVersion und die AssemblyFileVersion. Erstere wird von der CLR verwendet und letztere bekommt man z.B. im Windows Explorer in den Dateigenschaften zu Gesicht. Erhöht man also nur die AssemblyFileVersion, so wird die neue Version trotzdem ohne Beanstandung von der CLR geladen. Allerdings nicht die schönste Lösung wenn man wie ich Perfektionist ist sich selbst an dieser Unstimmigkeit stört.

Lösung 2: Über ein BindingRedirect in der App.Config kann die Verweisauflösung an eine neuere Assembly weitergereicht werden. Dafür erstellt man eine neue Anwendungskonfigurationsdatei sofern noch keine vorhanden ist, und ergänzt diese um folgenden Knoten:

Diese angeben müssen natürlich noch an die eigene Assembly angepasst werden. Eine genaue Beschreibung dieser Konfigurationsknotens gibt es in der MSDN: <bindingRedirect>-Element

Für weitere Methoden mit welchen sich das Binding umleiten lässt, und welche vielleicht komplett per Code machbar sind, wäre ich sehr Dankbar.

In den letzten Tagen habe ich wieder ein wenig am assemblyCompressor gearbeitet. Neu ist vor allem die Oberfläche.

Ich war ja immer schon ein Freund von dem, erstmals in Office 2007 verwendeten, Ribbon-UI. In Windows 7 wurde da ganze ja noch ein wenig weiter getrieben, so dass auch Standardanwendungen wie Paint oder Wordpad die neue Oberfläche erhielten. Ganz in diesem Stil habe ich nun auch die Oberfläche vom neuen assemblyCompressor gestaltet:

So hat man das wesentliche immer im Blick und kommt trotzdem schnell an alle Optionen heran. Wie der Fenstertitel verrät handelt es sich noch um eine Betaversion. An den Menus werde ich noch ein wenig arbeiten aber ansonsten gefällt mir diese Version schon recht gut. Alle übrigen Controls bleiben natürlich im nativen OS-Look, ich möchte die Anwendung ja nicht verschandeln, wie das manche mit diesem grässlichen Krypton-UI machen.

Download: assemblyCompressor2.zip(~2,10 MB)

Bei der Versionsnummer bin ich mir noch nicht so sicher, da es ja keine wirkliche Version 1.0 gab ist es ein bisschen Doof gleich auf 2.0 zu springen. Das ist ja nicht Googles Chrome. Wir werden sehen. Wer sich mit den Ribbons nicht anfreunden kann, kann den assemblyCompressor wie gewohnt auch komplett über die Kommandozeile betrieben. Dafür selbigen einfach in einer Konsole mit den Parametern “/build /help” ausführen um eine Liste mit den verfügbaren switches zu bekommen.

Im übrigen wird dieses Ribbon-UI wohl auch im updateSystem.NET mit dem nächsten oder übernächsten Minor-Update Einzug halten. Grade dort ist dies mehr als praktisch.