Weblog @ rebex.cz

Weblogy na webu Rebexu
Welcome to Weblog @ rebex.cz Sign in | Help
in Search

Problems presenting features of interest

  • Open Source UI komponenty pro .NET Compact Framework

    Hledal jsem něco, co by na Pocket PC zobrazovalo seznam strukturovaných prvků (s vlastním kreslením), a našel OwnerDrawnList.

    Co je na tom prvku opravdu chvályhodné je jeho zapouzdření: přidal jsem soubor s několika třídami do svého projektu a zdědil z něj svůj seznam, aniž bych v bázové třídě musel cokoli měnit. Až budu potřebovat další UI prvky, rozhodně mrknu na OpenNETCF.org.

  • Příliš chytrý HttpWebRequest

    Třída System.Net.HttpWebRequest irituje mnoho svých uživatelů. Mě taky.

    Pro testování HTTP serveru (programoval jsem do IIS jakousi extenzi) jsem potřeboval skriptovatelného HTTP klienta, který jednoduše pošle HTTP request (respektive spoustu identických requestů) s nastavenou hlavičkou Authorization a změří jak dlouho trvá čekání na odpověď. Naprogramovat prototyp v .NET šlo docela dobře - HttpWebRequest má property Credentials, které se dá přiřadit instance NetworkCredential (která se inicializuje jménem a heslem), a podpora threadů umožňuje efektivní paralelizaci požadavků bez komplikací meziprocesové komunikace - jenže když jsem to spustil, selhával testovací klient mnohem dřív než testovaný server... První požadavek prošel, ale když jsem se podíval, co server dostává, zjistil jsem, že odpovídá na dva: první bez autorizace (podle konfigurace - dodneška nevím čeho - může také dostat autorizaci Negotiate, obsahující jakási binární data), který je samozřejmě odmítnut, a až potom požadavek, který jsem chtěl poslat. Co hůř, v multithreadovém klientovi neunese HttpWebRequest svou vlastní složitost a pro polovičku requestů vyhodí vyjímku, že prý ho server nechce autorizovat...

    Napsal jsem si vlastní kód skládající autorizační header:

    StringBuilder sb = new StringBuilder();
    sb.Append("Authorization: Basic ");
    byte[] cred = new byte[user.Length + 1 + password.Length];
    int idx = 0;
    for (int i = 0; i < user.Length; ++i)
    {
        cred[idx++] = (byte)(user[i]);
    }
    cred[idx++] = (byte)':';
    for (int i = 0; i < password.Length; ++i)
    {
        cred[idx++] = (byte)(password[i]);
    }
    sb.Append(System.Convert.ToBase64String(cred));
    
    
    Tak končí vysokoúrovňová rozhraní... A stejně to nepomohlo: klient s tímto kódem sice posílá pouze jeden požadavek, ale multithreading stále selhává (přičemž požadavky z paralelně běžících procesů projdou, takže problém těžko bude na serveru).

    Pro marketingový materiál není tak těžké odfajfkovat: .NET má třídy pro internetové protokoly, .NET podporuje multithreading. Implementace bývá problematičtější...

  • K čemu je .NET security

    Na věcech, které se nesmí, se Microsoft v .NET opravdu vyřádil. Tradiční "role-based security" (tj. omezení podle uživatele) zobecňuje .NET na "evidence-based security", tj. omezení podle celkem čehokoli. Praktický příklad:

    Mám .NET komponentu (která není zadarmo), a chtěl bych k ní udělat demo aplikaci. Problém je, že přibalím-li komponentu k demu, může jí používat i jakýkoli jiný klient, a jak by řekl Jára Cimrman, to už pak snad ani není demo... Kdybych pracoval nad skutečným, nikoli virtuálním hardwarem, stačilo by zkompilovat do jednoho spustitelného souboru, ale .NET funguje jinak: veškerá rozhraní implementovaná v .NET assembly jsou z něj exportovaná - i když je to assembly třeba spustitelný soubor - a deklarovat rozhraní jako privátní nikomu nebrání, aby ho stejně nezavolal (akorát se to volání nedá přeložit, ale to je pouze omezení překladače - dynamický přístup pomocí reflexe funguje). Správným řešením je specifikovat povolení ("povolení" ve smyslu co není povoleno, je zakázáno), konkrétně StrongNameIdentityPermission.

    Dokumentace Microsoftu k tomuto atributu není nijak zvlášť informativní; naštěstí už někdo udělal příklad. Popsaný postup mi připadá hodně nelogický - přidávání klíče zkompilované komponenty do jejích zdrojáků svědčí o totálním nezájmu architektů zabezpečovacího mechanismu o automatizovaný build - ale nic jiného holt nefunguje...

  • Proč programovat .NET v C#

    Dodneška jsem si myslel, že rozdíly mezi VB.NET a C#.NET jsou čistě syntaktické. Jak říká bílý papír “Differences Between Microsoft Visual Basic .NET and Microsoft Visual C# .NET“ (ke stažení z http://support.microsoft.com/?kbid=308470), “Visual Basic .NET and Visual C# .NET are both first-class programming languages that are based on the Microsoft® .NET Framework, and they are equally powerful”. Jenže to říká na straně jedna... Rozdíly popsané na dalších 14 stranách se mohou zdát nepodstatné (kdo by chtěl používat ukazatele ve VB.NET, že ano...), ale mají přinejmenším jeden velmi praktický důsledek: VB.NET nedokáže volat všechny funkce Windows API. Jak je popsáno na
    http://www.experts-exchange.com/Programming/Programming_Languages/Dot_Net/Q_20708310.html, předávání ukazatele do funkce Windows CE SetSystemTime (ve Windows XP se tatáž fukce z VB.NET zavolat dá) je nutno napsat v C#. Z vlastní trpké zkušenosti to mohu potvrdit...
More Posts « Previous page
Powered by Community Server (Personal Edition), by Telligent Systems