seeseekey.net - Invictus Deus Ex Machina

Seit 2007 kann man bei der Ent­wick­lung mit­tels .NET in den Quell­text des Frame­works debug­gen. So kann man Feh­ler fin­den wel­che mit dem Unter­bau zusam­men­hän­gen, was durch­aus mal vor­kommt.

referencesource.microsoft.com

Wäh­rend man in den frü­hen Ver­sio­nen den Quell­text nur mit­tels des Visual Stu­dios anschauen konnte, gibt es nun seit eini­ger Zeit auch eine Mög­lich­keit dies Online zu tun. Auf der Seite referencesource.microsoft.com kann sich der Quell­text des gesam­ten .NET Frame­works pro­blem­los im Brow­ser ange­zeigt wer­den. Lizen­ziert ist das ganze dabei unter der Micro­soft Refe­rence Source License (MS-RSL).

Bei EncFS han­delt es sich um eine Imple­men­tie­rung eines Ver­schlüss­lungs­sys­tems für beste­hende Datei­sys­teme. Bei die­sem Sys­tem wird jede Datei für sich ver­schlüs­selt und das dar­un­ter lie­gende Datei­sys­tem genutzt. Neben der Ori­gi­nalim­ple­men­tie­rung von EncFS gibt es auch Por­tie­run­gen in andere Pro­gram­mier­spra­chen. Mit die­sen Por­tie­run­gen kön­nen EncFS ver­schlüs­selte Daten auch unter Java und .NET aus­ge­le­sen werden.

Die Java­va­ri­ante von EncFS trägt dabei den Namen „encfs-java“ und ist auf Git­Hub zu fin­den. Neben die­ser gibt es auch eine Vari­ante für .NET wel­che in C# geschrie­ben ist und auf Bit­Bu­cket zu fin­den ist. Ursprüng­lich han­delt es sich bei „encfs-dotnet“ um eine Por­tie­rung von „encfs-java“. Mitt­ler­weile wurde diese Imple­men­tie­rung aber kom­plett neu geschrie­ben. Wie bei der Ori­gi­nalim­ple­men­tie­rung, han­delt es sich auch bei den Por­tie­run­gen um freie Soft­ware. Die Java-Portierung steht dabei unter der GPL, wäh­rend die .NET Imple­men­tie­rung unter der LGPG steht, was deren Ver­wen­dung fle­xi­bler gestaltet.

Wei­tere Infor­ma­tio­nen gibt es unter:
https://de.wikipedia.org/wiki/EncFS

Möchte man in einer .NET respek­tive Mono­spra­che einen Anwen­dung schrei­ben wel­che mit der Twit­ter API inter­agiert, so sollte man hier­für eine Biblio­thek nut­zen um den Auf­wand in Gren­zen zu halten.

tweetinvi.codeplex.com

Eine emp­feh­lens­werte Bibli­to­thek in die­sem Bereich ist dabei Tweet­invi wel­che auf Code­P­lex zu fin­den ist. Tweet­invi ist dabei unter der Micro­soft Public License lizen­siert und somit freie Soft­ware. Die Biblio­thek ist dabei pro­blem­los in der Lage meh­rere Mil­lio­nen Tweets zu ver­ar­bei­ten und befin­det sich in akti­ver Ent­wick­lung. Ein ein­fa­ches Bei­spiel um einen Tweet abzu­set­zen könnte dabei so aussehen:

IToken token=new Token(twitterAccessToken, twitterAccessTokenSecret, twitterConsumerKey, twitterConsumerSecret);
ITweet tweet=new Tweet(tweetText, token);
bool success=tweet.Publish();

Damit hätte man den ers­ten Tweet mit die­ser Biblio­thek abgesendet.

Manch­mal möchte man eine Zei­chen­kette im Arbeits­spei­cher nicht län­ger als nötig im Klar­text vor­hal­ten. Hier­für gibt es unter .NET/Mono die Klasse „Secu­re­String“. Diese ver­schlüs­selt den Klar­text, so das die­ser nicht ohne wei­te­res im Spei­cher zu fin­den ist. Lei­der ist die Nut­zung der „Secu­re­String“ etwas komplizierter:

SecureString secureString=new SecureString();
secureString.AppendChar('g');
secureString.AppendChar('e');
secureString.AppendChar('h');
secureString.AppendChar('e');
secureString.AppendChar('i');
secureString.AppendChar('m');

// in Klartext umwandeln
IntPtr secureStringPointer=Marshal.SecureStringToBSTR(secureString);
string klartext=Marshal.PtrToStringAuto(secureStringPointer);

Hier muss man abwä­gen, ob sich die Nut­zung eines sol­ches Kon­struk­tes lohnt, oder man wei­ter­hin nor­male Strings für sen­si­ble Daten nutzt.

Unter .NET ist es manch­mal sehr nütz­lich zu wis­sen, ob an die Anwen­dung ein Debug­ger ange­hängt ist. Im Name­space „System.Diagnostics“ gibt es dazu auch die pas­sende sta­ti­sche Eigen­schaft mit dem Namen „IsAt­ta­ched“. Die Nut­zung könnte dabei so aussehen:

if(Debugger.IsAttached==true)
{
    //Do something
}

Der Quell­text in den Block­klam­mern wird dabei nur dann aus­ge­führt, wenn ein Debug­ger an die Anwen­dung ange­han­gen ist. Das kann die IDE (Visual Stu­dio und Co.) sein, es kann aber auch ein bös­wil­li­ger Angrei­fer sein — wobei es natür­lich Ver­fah­ren gibt, die Erken­nung auszuhebeln.

Unter .NET gibt es eine Reihe von Attri­bu­ten, wel­che für ver­schie­denste Zwe­cke not­wen­dig sind. Natür­lich ist es inter­es­sant zu erfah­ren wel­che Attri­bute es gibt. Auf den ers­ten Blick sieht es so aus, als ob es in der MSDN von Micro­soft keine Auf­lis­tung der Attri­bute gibt.

Die Auf­lis­tung der Attri­bute in der MSDN

Beim genaue­ren Hin­schauen, wird man bemer­ken das es diese Liste gibt. Attri­bute wer­den in .NET von der „Attribute“-Klasse abge­lei­tet. Wenn man sich die Doku­men­ta­tion für diese Klasse anschaut wird man fest­stel­len, das es unten einen Bereich „Inheri­tance Hier­ar­chy“ gibt, wel­cher alle abge­lei­te­ten Klas­sen auf­lis­tet und somit auch alle Attribute.

Im Web kennt man sol­che Boxen zu genüge. Ein Such­feld in wel­chem in aus­ge­grau­ter Schrift „Suchen“ oder ähn­li­ches steht. Unter .NET ist das ganze lei­der nicht als vor­ge­fer­tig­tes Con­trol vor­han­den, so das man hier selbst Hand anle­gen muss. Für ein sol­ches Con­trol nimmt man eine Text­Box und setzt die Events „Enter“ und „Leave“ und befüllt sie wie folgt:

string grayedText="Search...";

private void tbSearch_Enter(object sender, System.EventArgs e)
{
	if(tbSearch.Text==""||tbSearch.Text==grayedText)
	{
		grayedText=tbSearch.Text;
		tbSearch.Text="";
		tbSearch.ForeColor=Color.Black;
	}
}

private void tbSearch_Leave(object sender, System.EventArgs e)
{
	if(tbSearch.Text=="")
	{
		tbSearch.ForeColor=Color.Gray;
		tbSearch.Text=grayedText;
	}
}

Damit steht in der Text­Box der aus­ge­graute Text „Search…“ wel­cher ver­schwin­det, sobald man den Fokus in die Text­Box setzt. Der Platz­hal­ter­text wird nur dann ange­zeigt, wenn kein Inhalt in der Text­box vor­han­den ist.

Wenn man mit nicht von einer Cer­ti­fi­cate Aut­ho­rity signier­ten Zer­ti­fi­ka­ten arbei­tet, so wird man frü­her oder spä­ter fol­gende Feh­ler­mel­dung unter .NET zu sehen bekommen.

Das Remotezertifikat ist laut Validierungsverfahren ungültig.

Gege­ben sei dabei fol­gen­des Beispiel

SmtpClient client=new SmtpClient(host, port);
client.EnableSsl=true;

SSL ist zwar akti­viert, aber das Zer­ti­fi­kat kann in die­sem Fall nicht vali­diert wer­den. Eine Methode um die Vali­die­rung abzu­schal­ten ist dabei fol­gen­den Ein­zei­ler über diese Zei­len zu schreiben:

ServicePointManager.ServerCertificateValidationCallback=delegate { return true; };

Danach bekommt man keine Zer­ti­fi­kats­war­nung mehr und kann die Ver­bin­dung nutzen.

Der Kindle als eBook Rea­der macht vie­les rich­tig. Nur beim Über­tra­gen von eige­nen Doku­men­ten wird es schwie­rig. Es gibt zwar die Mög­lich­keit Doku­mente per Mail oder USB auf den Kindle zu brin­gen, aller­dings wird das in man­chen Fäl­len etwas umständlich.

Der Kindle Paper­white im aus­ge­schal­te­ten Zustand

So bie­tet Ama­zon eine Kon­ver­tie­rung von PDFs in ein auf dem Kindle les­ba­res For­mat an. Um das ganze zu ver­ein­fa­chen, habe ich eine kleine Anwen­dung namens „Kindle Uploa­der“ geschrie­ben. Nach der Kon­fi­gu­ra­tion kann man ganze Ord­ner oder auch ein­zelne Dateien an sei­nen Kindle sen­den. Mit Hilfe der Option „-con­vert“ ist es mög­lich die Kon­ver­tie­rung in das AZW For­mat (für bes­sere Les­bar­keit) anzustoßen:

kindleuploader.exe -convert test.pdf folder test.txt

Die Anwen­dung ist dabei freie Soft­ware unter der GPLv3 und kann auf Git­Hub „besich­tigt“ wer­den. Alter­na­tiv kann das ganze als aus­führ­bare Datei her­un­ter­ge­la­den werden.

Manch­mal ist Mono Deve­lop etwas undurch­sich­tig. So bekam ich bei einem Pro­jekt wel­ches ich neu kom­pi­lie­ren wollte mehr­mals die Fehlermeldung:

Error CS1904: `' is not a valid warning number (CS1904) (CSCL)

Der Com­pi­ler beschwert sich hier­bei dar­über, das eine spe­zi­fi­zierte War­nungs­num­mer nicht exis­tiert. Aller­dings ist es schwie­rig eine nicht vor­han­dene Num­mer zu finden.

Die Com­pi­ler Optionen

Die Lösung lag in den Com­pi­ler Optio­nen des Pro­jek­tes. Hier befand sich unter „War­nun­gen igno­rie­ren“ die Zeile:

0168 ; 0169; 0414; 0618; 0649

Das Pro­blem an die­ser Zeile waren die Leer­zei­chen, wel­che von Mono­De­ve­lop als zu igno­rie­rende War­nun­gen inter­pre­tiert wur­den. Und eine War­nung ohne Num­mer kennt das Sys­tem natür­lich nicht. Nach dem Ent­fer­nen der Leer­zei­chen, kom­pi­lierte auch das Pro­jekt wieder.