Kategorie: Softwareentwicklung

Arbeitsplatz mit C# sperren 👍 👎

Das Sperren des Arbeitsplatzes lässt sich unter Windows beispielsweise über die Tastenkombination [Win] + [L] erreichen. Aber auch mit C# lässt sich dies sehr einfach per LockWorkStation und DllImport bewerkstelligen:
Wrapper implementieren
01020304
public static class Workstation {    [DllImport("user32", EntryPoint = "LockWorkStation")]    public static extern bool Lock();}
Die Verwendung gestaltet sich nun äußerst einfach und selbsterklärend:
Wrapper verwenden
01
Workstation.Lock();

Base64-Kodierung mit C# 👍 👎

Zur verlustfreien Speicherung und Übertragung von Binärdateien als Text kommt häufig die Base64-Kodierung zum Einsatz. C# unterstützt die (De-)Kodierung dieser Daten in ihrer üblichen Darstellungsform als Zeichenkette sehr komfortabel über die beiden Methoden Convert.ToBase64String und Convert.FromBase64String:
Base64-Konvertierung
01020304
byte[] input = Encoding.UTF8.GetBytes("Hällö!");   // [72, 195, 164, 108, 108, 195, 182, 33]
string base64 = Convert.ToBase64String(input); // "SMOkbGzDtiE="byte[] output = Convert.FromBase64String(base64); // [72, 195, 164, 108, 108, 195, 182, 33]
Die verbreitete Darstellung mit Zeilenumbrüchen nach jeweils 76 Zeichen wird durch die Option Base64FormattingOptions.InsertLineBreaks ermöglicht.

Spannender als mit einer einfachen Zeichenkette ist dieses Vorgehen natürlich bei komplexen Dateien, wie sie beispielsweise im Zusammenhang mit X.509-Zertifikaten auftreten. Praktisch ist dies, da die kodierte Zeichenkette nur noch aus lesbaren ASCII-Zeichen besteht und folglich keine Probleme mit Zeichensätzen zu erwarten sind. Darüber hinaus können derart kodierte Grafiken beispielsweise direkt in Webseiten eingebettet werden.

Offensichtlich sollte dieses Verfahren jedoch nicht zur "Verschlüsselung" sensibler Daten verwendet werden.

Richtlinien für grafische Benutzeroberflächen unter Windows 👍 👎

In einem früheren Beitrag hatte ich bereits die Framework Design Guidelines verlinkt, welche einen Leitfaden zur Implementierung von Backend-Funktionalität, insbesondere in Form von Programmbibliotheken, darstellen.

Nun wurde ich auf die OS X Human Interface Guidelines aufmerksam gemacht und in diesem Zusammenhang gefragt, ob es so etwas auch für Windows gibt. Auch von Microsoft gibt es entsprechende Informationen: Im Windows Dev Center lassen sich viele weitere Hinweise zur Entwicklung eigener Anwendungen finden.


PS: Der Vollständigkeit wegen sei auch auf Material design von Google hingewiesen.

(De-)Kompression mit C# 👍 👎

Zwar ist Speicher heutzutage üblicherweise keine Mangelware mehr, dennoch kann sich die Komprimierung großer Datenmengen, beispielsweise zur Übertragung, lohnen. C# bietet dazu einige Möglichkeiten, so unter anderem zur Arbeit mit ZIP-Archiven. Zu diesen möchte ich jedoch in einem separaten Beitrag kommen und stattdessen zeigen, wie sich mit der DeflateStream-Klasse beliebige Daten(-ströme) (de-)komprimieren lassen:
(De-)Komprimierung von Rohdaten
01020304050607080910111213141516171819202122232425
  // Daten komprimierenpublic static byte[] Compress(byte[] data) {    using(MemoryStream inStream = new MemoryStream(data)) {        using(MemoryStream outStream = new MemoryStream()) {            using(DeflateStream deflate = new DeflateStream(outStream, CompressionMode.Compress)) {                inStream.CopyTo(deflate);            }
return outStream.ToArray(); } }}
// Daten dekomprimierenpublic static byte[] Decompress(byte[] data) { using(MemoryStream inStream = new MemoryStream(data)) { using(MemoryStream outStream = new MemoryStream()) { using(DeflateStream deflate = new DeflateStream(inStream, CompressionMode.Decompress)) { deflate.CopyTo(outStream); }
return outStream.ToArray(); } }}
Um beispielsweise komplette Dateien effizient zu (de-)komprimieren, kann wie folgt vorgegangen werden:
(De-)Komprimierung von Dateien
010203040506070809101112131415161718192021
  // Datei komprimierenpublic static void CompressFile(string inputPath, string outputPath) {    using(FileStream inStream = File.OpenRead(inputPath)) {        using(FileStream outStream = File.OpenWrite(outputPath)) {            using(DeflateStream deflate = new DeflateStream(outStream, CompressionMode.Compress)) {                inStream.CopyTo(deflate);            }        }    }}
// Datei dekomprimierenpublic static void DecompressFile(string inputPath, string outputPath) { using(FileStream inStream = File.OpenRead(inputPath)) { using(FileStream outStream = File.OpenWrite(outputPath)) { using(DeflateStream deflate = new DeflateStream(inStream, CompressionMode.Decompress)) { deflate.CopyTo(outStream); } } }}
Sofern zusätzlich verschlüsselt werden soll, worauf ich in einem separaten Beitrag näher eingehen möchte, ist eine sinnvolle Reihenfolge zu beachten. Diese trägt zwar, abgesehen von kleineren Umständen bei unberechtigten Entschlüsselungsversuchen, nicht wesentlich zur Sicherheit an sich bei – wohl aber zur erzielbaren Kompression.

Die (verlustfreie) Datenkompression basiert hauptsächlich auf Redundanzreduktion. Es werden also Muster der Eingabe erkannt und kompakter kodiert. Derartige Muster sollten nach einer ordnungsgemäßen Verschlüsselung jedoch nicht auftreten, d. h. die Ausgabe wirkt ohne Schlüssel weitestgehend zufällig. Verschlüsselte Daten lassen sich entsprechend schlecht komprimieren und so lässt sich sogar recht einfach prüfen, ob eine Verschlüsselung grobe Fehler aufweist – nämlich genau dann, wenn eine signifikante Kompression des Chiffrats möglich ist.

Konkret bedeutet dies also für die Praxis üblicherweise, zuerst zu komprimieren und danach zu verschlüsseln.

.NET-Guidelines für Programmbibliotheken 👍 👎

Da es in Projekten im Allgemeinen des Öfteren zur Frage kommt, wie Member benannt und strukturiert werden sollen und ich erst vor Kurzem im Büro darauf hingewiesen habe, möchte ich auch an dieser Stelle einmal auf die Framework Design Guidelines von Microsoft hinweisen, welche einen Leitfaden zur Implementierung darstellen.

Wichtig zu verstehen ist dabei, dass sich diese Richtlinien nur auf die öffentliche Schnittstelle (also insbesondere Member mit public- oder protected-Modifizierer) beziehen und grundsätzlich keine Aussagen zu internen (private-Modifizierer) Membern treffen. Es bietet sich jedoch durchaus an, auch hier konform zu gehen. Die Einleitung weist auch explizit darauf hin, dass ein – gut begründetes – Abweichen von diesem Regelwerk legitim ist.

Im MSDN findet sich im Übrigen auch eine Übersicht der Warnungen bei der Analyse von verwaltetem Code.

Projektverweise

Kategorien / Archiv  |  Übersicht RSS-Feed

Schlagworte

Suche