Uložení důležitého stavu serverových ovládacích prvků v ASP.NET 2.0

ASP.NET 1.0 přineslo pro vývojáře WWW aplikací několik zásadních novinek. Jednou z nejlepších je simulace stavového chovaní prvků pomocí ViewState. U každého serverového ovládací prvku je před vyrenderováním stránky volána metoda SaveViewState, ve které prvek uloží všechny informace potřebné k obnovení stavu. Kompletní stavová informace stránky je poté uložena ve skrytém (hidden) poli na klientovi. Po odeslání formuláře (PostBacku) je volána metoda LoadViewState všech prvků a je jí předán stav uložený metodou SaveViewState. Metoda LoadViewState obnoví stav prvku a poskytne tak vývojáři i uživateli skoro dokonalou iluzi stavového chování známého hlavně z těžkých klientů. Slovo "skoro" jsem použil záměrně, protože je často nutné z výkonnostních důvodů ukládání ViewState zakázat, aby na klienta a pak zpět na server nebyly přenášeny velké objemy dat. Můžeme sice přepsat metody LoadViewStateFromPersistenceMedium a SaveViewStateToPersistenceMedium třídy Page a ukládat ViewState například do databáze na serveru, ale v praxi se tento postup příliš neujal. Ukládání ViewState můžeme zakázat všem ovládacím prvkům na stránce, častěji ale ukládání ViewState zakážeme pouze u vybraných prvků, jež by do ViewState přidaly nejobjemnější položky. Po zakázání ViewState se ale většinou setkáme s problémy, jejichž řešení zabere nezanedbatelné množství času. Například DropDownList si po zákazu ViewState "nepamatuje" vybranou položku (SelectedIndex), takže uložení a nastavení indexu vybrané položky musíme při každém odeslání formuláře řešit sami. ViewState v .Net Frameworku 1.0 vyznává zásadu "všechno nebo nic", ale my bychom často potřebovali ukládat důležitý stav bez ohledu na nastavení ViewState vývojářem. Nemusíme ukládat do ViewState zrovna celý číselník, ale index vybrané položky přenosovou linku nijak nezatíží a programování extrémně zjednoduší.
ASP.NET 2.0 proto přichází s novinkou - kromě ViewState lze ukládat i takzvaný ControlState. O ukládání do ControlState rozhoduje výhradně vývojář serverového ovládacího prvku, jehož odpovědností je, aby do ControlState byla uložena jen data důležitá pro základní činnost prvku. Určitě ale do ControlState nesmí být ukládány DataSety, kolekce ani jiné objemné objekty. Dále platí, že stavová data jsou uložena do ControlState nebo do ViewState, nikdy ne do obou stavových úložišť! Výsledný ControlState celé stránky je ukládán na klientovi ve skrytém poli s nepřekvapivým názvem __CONTROLSTATE.
Ukládání do ControlState se příliš neliší od ukládání do ViewState. Hlavním rozdílem je to, že serverový ovládací prvek si musí vynutit ukládání a načítání ControlState voláním metody RegisterRequiresControlState třídy Page.

protected override void OnInit(EventArgs e)
{
   base.OnInit(e);
  Page.RegisterRequiresControlState(this);
}

Ve veřejné metodě SaveControlState před vyrenderováním stránky uložíme důležitý stav prvku a vrátíme jej. Návratovým typem metody je typ object, takže můžeme vrátit jakýkoli serializovatelný(!) objekt. V ukázkovém kódu je ukládán ControlState bázové třídy a poté hodnota vlastnosti SelectedIndex.

public override object SaveControlState()
{
  object baseState = base.SaveControlState();
   object[] savedSate = { baseState, this.SelectedIndex};
   return savedState;
}

Metoda LoadControlState po odeslání formuláře obnoví dříve uložený ControlState. Z argumentu state je po přetypování obnoven nejdříve ControlState bázové třídy a poté hodnota vlastnosti SelectedIndex.

public override void LoadControlState(object state)
{
   object[] savedState =(object[]) state;
   base.LoadControlState(savedState[0]);
   this.SelectedIndex = (int) savedState[1] ;
}

Friday, 07 May 2004 15:47:00 (Central Europe Standard Time, UTC+01:00)       
Comments [2]  ASP.NET

Windows forms combobox jen pro čtení

Nedávno jsem potřeboval zakázat v detailu uživateli výběr z comboboxu, ale zjistil jsem, že první nabízející se cesta přes vlastnost Enabled není vhodná. Když nastavíte vlastnost Enabled na false, tak sice uživatel žádnou položku nevybere, ale combobox působí na formuláři jako grafický "umrlec",  protože dříve vybraná položka je "zašeděná". Potřeboval jsem vlastnost, která by ponechala vizuální vzhled comboboxu beze změny, ale nedovolila provést nový výběr.
Žádnou takovou vlastnost jsem nenašel, a proto jsem vytvořil potomka comboboxu, kterému jsem přidal vlastnost DisableDropDown. Když je vlastnost DisableDropDown true, tak combobox v přepsané metodě OnWndProc ignoruje zprávy o stisku tlačítka myši (WM_LBUTTONDOWN a WM_LBUTTONDBLCLK) a zprávy z klávesnice (WM_KEYDOWN, WM_KEYUP) . V další přepsané metodě OnKeyPress combobox zamezí zadání nové položky do textového pole nastavením vlastnosti Handled argumentu e na true. To je celý trik, snad se bude odvozený combobox hodit i Vám.

using

System;

using

System.Windows.Forms;

namespace

RStein.UI

{

  /// <summary>

  /// Combobox, u nějž je možné zakázat rozbalení seznamu položek a editaci textového pole

  /// </summary>

  public class ComboBoxEx : ComboBox

  {

    private const int WM_KEYDOWN = 0x0100;

    private const int WM_KEYUP = 0x0101;

    private const int WM_LBUTTONDOWN = 0x0201;

    private const int WM_LBUTTONDBLCLK = 0x0203;

 

   #region

private fields

   private bool m_disableDropDown = false ;

   #endregion

private fields

   /// <summary>

   /// Konstruktor

   /// </summary>

   public ComboBoxEx()

   {

     m_disableDropDown =

false ;

   }

  #region

public properties

  /// <summary>

  /// Zakázat zobrazení položek?

  /// </summary>

  public bool DisableDropDown

  {

    get

    {

      return m_disableDropDown;

    }

   set

   {

      m_disableDropDown =

value ;

   }

  }

  #endregion

public properties

 

  #region

protected methods

  protected override void OnKeyPress(KeyPressEventArgs e)

  {

    if (!DisableDropDown)

     base .OnKeyPress(e);

    else

     e.Handled = true;

   }

  protected override void WndProc(ref Message m)

  {

    if (!DisableDropDown)

      base.WndProc (ref m);

    else if ((m.Msg != WM_KEYDOWN) &&

                (m.Msg != WM_LBUTTONDOWN ) &&

               (m.Msg != WM_LBUTTONDBLCLK) &&

             (m.Msg != WM_KEYUP))

              base.WndProc (ref m);

  }

  #endregion

protected methods

  }

}

Thursday, 06 May 2004 21:15:00 (Central Europe Standard Time, UTC+01:00)       
Comments [0]  Windows Forms

DIGI TRADE součástí skupiny PC-WARE
Firma DIGI TRADE, ve kterém jsem zaměstnán, se včera stala součástí mezinárodní skupiny PC-WARE. Další krok za námi, vypadá to, že se můžeme těšit na rozsáhlé a doufám i komplikované mezinárodní projekty. Nové zkušenosti, příležitosti, žádný stereotyp, přesně to, co mám rád. U sklenky šampaňského také doufám, že se nám vyhnou mezinárodní průšvihy, ty internacionalizovat nemusíme.:)

Thursday, 06 May 2004 13:44:00 (Central Europe Standard Time, UTC+01:00)       
Comments [3]  Ostatní

Moderní architektura očima Microsoftu aneb rozpaky nad vizemi

Na konferenci, jejíž název je v titulku spotu, jsem strávil dnešní den. Microsoft na ní po úvodní přednášce prezentoval hlavně BizTalk, takže jsem ji bral jako pokračování praktického semináře z minulého týdne. Úvodní přednášku měl Michael Juřek a vysvětloval v ní, jak Microsoft reaguje na požadavky firem integrovat existující aplikace bez velkých nákladů, ale přitom způsobem, který mezi aplikacemi nevytváří více a více se svírající osudové kruhy.
Určitě osudové kruhy znáte, aplikace A využívá databázi aplikace B, ta si sáhne do databáze aplikace C pro autorizované uživatele a na oplátku v aplikaci A vyřídí faktury. Aplikace D si také ráda sosne z jiných zdrojů a máme zde solidní mikromodel chaosu. Aplikace jsou těsně provázány a přitom neexistuje jediný závazný model jejich komunikace. Ano, nebojte se, padlo i magické zaklínadlo dnešních dnů, SOA, ale kupodivu v sále hysterie nepropukla, potože Michal Juřek naštěstí nepronáší pojem SOA tak vznešeně, jak by si fanoušci buzzwords asi přáli.:) Pokud tento spot čtou šťastlivci, kteří o SOA (Service oriented architecture) neslyšeli, tak vězte, že Microsoft se přklonil k této definici služby - "Služba je autonomní část software, která implementuje logiku v podobě kódu, spravuje svůj stav, komunikuje prostřednictvím zpráv, je řízena politikou a je dostupná po síti". Když se nad touto definicí zamyslíte, tak zjistíte, že ji asi můžete napasovat na jakoukoli komponentu. Dosti žertování, bez ohledu na zbytečný humbuk kolem SOA je opravdu zřejmé, že se již dnes stále více prosazují integrace na bázi WWW služeb, u nichž nás nezajímá implementace, ale pouze struktura platformně a infrastrukturně nezávislých zpráv, které jim mohu zaslat a které mi pošlou jako odpověď. Jinými slovy, zajímá mě jen závazný protokol pro výměnu zpráv (kontrakt) mezi mnou a službou, vše ostatní je zcela irelevantní. Cílem integrací je také zrušení těsných závislostí mezi aplikacemi nasazením inteligentního prostředníka, který jejich spolupráci koordinuje. Na platformě Microsoftu je tímto integrátorem (brokerem) BizTalk.

Mimochodem - víte, kdy začnu respektovat fanoušky SOA? Až dokážou napsat WSDL WWW služby ke komponentě z hlavy - tomu říkám znalost technologie a respekt k ní:)

Nejen tato, ale i další přednášky Michala Juřka se mi líbily. Horší to bylo s částmi, které měl na starosti Miloš Sobotka.  Jeho prezentace byly velmi nekonvenční, takže jsem brzy nabyl dojmu, že ho Microsoft předtím omylem vyslal na kurz asertivity místo potřebného kurzu prezentačních dovedností . Jeho ústní projev byl plný pomocných frází, zaumných přeřeknutí a rozverných anglicismů, přednáška neměla žádnou logickou kostru, prezentace dema vetšinou nedopadla podle jeho představ, ale všechnny tyto nedostatky zvládl s labilním smíchem asertivně bagatelizovat a vystavit jako přednost.:) Nebyly to informačně hodnotné přednášky, ale docela jsem se pobavil.:)

Na konci konference byly zodpovězeny naše dotazy a dostalo se i na vztah Microsotu k UML. UML 2.0 má silnou podporu pro modelování dynamického chování, a proto asi nejen mě zajímalo, jestli se v BizTalku i dalších produktech návrh procesů v UML objeví. Zvláště poté, co prosákly zprávy, že Microsoft k UML dobrý vztah nemá. Bohužel, nešlo o žádné pomluvy, Microsoft si s UML opravdu nerozumí. Já ale zase asi nerozumím Microsoftu. Jak může na konferenci o moderní architektuře bezelstně přiznat, že mu jeden z nejdůležitějších nástrojů analytika, designéra a architekta nesedí? Proč se chce vydělit z MDA iniciativy?

Oficiálně byly sděleny zatím tyto důvody pro vlažný vztah k UML.
1) UML je pro běžného vývojáře příliš komplikované. Microsoft se vždy údajně orientoval na "masového" vývojáře, který nemá žádné komplikované věci rád,  a UML by tuto orientaci popřelo. Opravdu je pro Vás, kdo tento spot čtete, UML složité? A hlavně,  v čem je pro Vás složité? Mně přijde jako jednoduché, čisté a elegantní. Znamená to, že JAVA vývojáří UML zvládnou, ale C# vývojář má potíže? Já myslím, že ne a že jde o pouhý alibismus kvůli bodu 2. Jsem také skeptický v tom, že Microsoft by přišel s něčím stejně výkonným jako je UML a přitom by šlo o jednodušší jazyk. Nechci hračky vhodné na splácání projektu o 10 třídách a odškrtnutí kolonky "Analýza hotova" v projektovém plánu.
2) Firma Rational Rose byla koupena IBM a IBM je konkurence, takže podpora UML by byla pro Microsoft schizofrenní. Tenhle argument už vypadá věrohodněji, protože Microsoft zcela jistě nebude podporovat konkurenci. Ale přesto, UML nepatří IBM, UML je průmyslový standard. Nevylévejte s vaničkou dítě, které má skvělé geny. A ty geny nejsou po adoptivních rodičích-vlastnících. Zásadovost je správná a konkurenci je třeba potřít, ale UML s tímhle bojem nemá nic společného. Vývojáři mohou použitím UML jen získat, ale UML je nesvede k laškování s IBM technologiemi. Věřte mi, jsem živý důkaz:)

Wednesday, 05 May 2004 20:14:00 (Central Europe Standard Time, UTC+01:00)       
Comments [15]  Analytické drobky

Oskar spustil víkendová volání "zdarma"

Náš benjamínek mezi mobilními operátory nabízí volání o víkendu zdarma všem novým zákazníkům, kteří si aktivují jeden z tarifů nové generace - Řekni mi (volání zdarma na 3 měsíce), Povídej (6 měsíců) a Nezavěšuj (12 měsíců). Zní to hezky, ale názvy PR zpráv většinou realitu přikrášlují, tak se podívejme, na kolik si u Oskara ocenili hovory "zdarma" pro stávající zákazníky.
Stávající zákazníci tedy nepřijdou zkrátka, ale nedostanou ani slevu zadarmo, a za neomezené víkendové hovory zaplatí měsíční poplatek 178,50. Jde sice o zajímavou nabídku, protože na českém telekomunikačním trhu jsou bezlimitní paušálně zpoplatněné hovory raritou, ale o žádný zázrak se nejedná. Oskar se snaží podobně jako dříve T-Mobile zatraktivnit volání v době, kdy je kapacita sítě málo využívána. Pochybuji ale, že se najde dostatek nadšených šílenců, kteří zaplatí 178 Kč, aby si mohli po telefonu poklábosit se svými známými v době, kdy mají volno a mohou je navštívit osobně. Napadají mě pouze odloučení zamilovaní, ti musí při uvedení tohoto tarifu jásat. :) Jako bonus by jim ale mohl Oskar k aktivaci tarifu přidávat handsfree sadu. Kdo již absolvoval delší hovor přes mobil, tak určitě ví proč.
Možná je ale Oskar fikanější a počítá s tím, že si tolik zákazníků tarif neaktivuje, ale přesto se bude moci prezentovat jako operátor, který má kapacitně tak naddimenzovanou síť, že si může dovolit nabízet neomezené hovory. Oskar má stale pověst laciného operátora, jehož síť ale za moc nestojí, a touto akcí by mohl získat cennou reputaci i v oblasti technické vyspělosti sítě, kterou marketingové oddělení jistě zúročí. Oskar se nám sice nyní v reklamách prezentuje jako adolescent, kterému nechybí sebevědomí a který ví, že všechny problémy zdolá svým roztomile naivním a neodolatelným sloganem"stačí říct", ale vědom si fyzických limitů GSM sítě nastavil podmínky provozování této služby přeci jen střízlivěji.

Ze závažných technických nebo provozních důvodů může Oskar přerušit nebo zastavit poskytování tohoto balíčku dle všeobecných podmínek.

Tuesday, 04 May 2004 16:43:00 (Central Europe Standard Time, UTC+01:00)       
Comments [4]  Mobilitky

Znáte třídy ServicePoint a ServicePointManager? Měli byste...

Při používání více threadů například pro získání obsahu WWW stránek ze stejného URI nebo při asynchronním a současně prováděném volání více metod jedné WWW služby se můžete setkat s podivnými výjimkami nebo ještě podivnějšími prodlevami mezi jednotlivými voláními.
Za rovnoměrné využití síťových zdrojů je odpovědná třída ServicePointManager. Ta obhospodařuje kolekci objektů ServicePoint, které jsou vytvářeny při prvním požadavku na dané URI. Třída ServicePointManager má několik zajímavých vlastností a metod.
Vlastnost DefaultConnectionLimit - hodnota vlastnosti určuje, kolik konkurenčních připojení může ve stejném okamžiku přistupovat ke stejnému URI. V .Net Frameworku 1.1 jsou ve výchozím nastavení povolena dvě konkurenční připojení na stejné URI. Jestliže například z nějakého důvodu potřebujete asynchronně a "najednou" volat více metod WWW služby, měli byste ConnectionLimit zvýšit.
Vlastnost MaxServicePointIdleTime - tato vlastnost říká, jak dlouho musí být dané URI neaktivní, aby se stalo kořistí Garbage Collectoru. Neaktivní znamená, že s daným URI nebylo po zadanou dobu vytvořeno žádné spojení. Výchozí hodnotou je 900.000 milisekund (15 minut)
Vlastnost MaxServicePoints - tato vlastnost říká, kolik instancí ServicePoint může být vytvořeno. Jinými slovy, tato vlastnost omezuje počet URI, na které se lze v jednom okamžiku připojit. Ve výchozím nastavení žádný limit neexistuje (vlastnost obsahuje hodnotu 0).
Metoda FindServicePoint - přetížená metoda FindServicePoint vrátí objekt ServicePoint pro zadané URI. Když ServicePoint pro URI ještě neexistuje, tak metoda vytvoří a vrátí nový objekt ServicePoint, jinak je vrácen existující ServicePoint.

U třídy ServicePoint můžeme upravit vlastnosti, jež jsou po vytvoření objektu inicializovány výchozími hodnotami převzatými z třídy ServicePointManager.

ConnectionLimit - má stejný význam jako vlastnost DefaultConnectionLimit u ServicePointManageru.
MaxIdleTime = má stejný význam jako vlastnost DefaultConnectionLimit u ServicePointManageru.

Tak a teď jednoduchý demonstrační kód konzolové aplikace. Nejdříve kód, který změní DefaultConnectionLimit tak, aby odpovídal počtu požadavků (WebRequest). Vše proběhne relativně rychle a dle očekávání.

using System;
using System.Net;
using System.Threading;
namespace RStein.ServicePointManagerTester
{
  class ServicePointManagerTest
  {
    static void Main(string[] args)
    {
      Console.WriteLine(ServicePointManager.DefaultConnectionLimit);
       ServicePointManager.DefaultConnectionLimit = 4;
       WebRequest reg = WebRequest.Create("http://wwww.atlas.cz");
       WebRequest reg2 = WebRequest.Create("http://wwww.atlas.cz");
       WebRequest reg3 = WebRequest.Create("http://wwww.atlas.cz");
       WebRequest reg4 = WebRequest.Create("http://wwww.atlas.cz");
       WaitHandle handle0 = reg.BeginGetResponse(new AsyncCallback(test), reg).AsyncWaitHandle;
       WaitHandle handle1 = reg2.BeginGetResponse(new AsyncCallback(test), reg2).AsyncWaitHandle;
       WaitHandle handle2 =reg3.BeginGetResponse(new AsyncCallback(test), reg3).AsyncWaitHandle;
       WaitHandle handle3 =reg4.BeginGetResponse(new AsyncCallback(test), reg4).AsyncWaitHandle;
       WaitHandle.WaitAll(new WaitHandle[] {handle0, handle1, handle2, handle3});
       Console.WriteLine("vse");
       Console.Read();
     }

     private static void test(IAsyncResult ar)
     {
       Console.WriteLine("Konec requestu");
       try
       {
         WebRequest reg = (WebRequest)ar.AsyncState;         

        WebResponse response = reg.EndGetResponse(ar);         

        response.GetResponseStream().Close();       

     }
       catch(Exception e)
       {
         Console.WriteLine(e.ToString());
       }
     }
   }
}
Nyní změňte DefaultConnectionLimit na 1. Jak můžete pozorovat, vyřízení všech požadavků je citelně pomalejší (alespoň u mě na GPRS), protože jsou vyřizovány jeden po druhém. K URI "www.atlas.cz" může vždy přistoupit pouze jedno připojení. Mimochodem, víte proč se v MSDN neustále zdůrazňuje, že je třeba co nejdříve uzavřít všechny použité streamy? Jestliže ne, upravte řádku response.GetResponseStream() Close() ; na response.GetResponseStream(); a spusťte znovu aplikaci.

Monday, 03 May 2004 21:21:00 (Central Europe Standard Time, UTC+01:00)       
Comments [6]  .NET Framework

T-Mobile ponechá tarif GPRS Unlimited za 699 Kč (bez DPH)

Jestliže jste to ještě nezaregistrovali, T-Mobile ve své tiskové zprávě oznámil, že ponechá cenu 699 Kč za neomezený přístup k Internetu přes GPRS. Předchozí cenově  zvýhodněný tarif GPRS Business Unlimited jsem si aktivoval ihned po jeho uvedení v listopadu a i když nejde o žádné zázračně rychlé připojení, na stahování pošty, připojení do VPN, prohlížení webu a psaní příspěvků do weblogu bohatě stačí. Vím ale, že vděčnost za tento tarif,  i podobný a dříve uvedený tarif Data Nonstop od Eurotelu, má svůj zdroj spíše v sebevražedné cenové politice žáby na prameni s internetovým připojením - Českým Telecomem.

V červnu se cena tarifu GPRS Business Unlimited měla vyšplhat na 999 Kč, ale T-Mobile se rozhodl jinak. Zdá se, že jeho rozhodnutí není jen nahodillým vstřícným gestem směrem k zákazníkům, ale spíše promyšlenou součástí dříve oznámeného ambiciozního plánu přestat být tím "stále druhým" na českém trhu. Jedničkou v počtu zákazníků i tržbách je stále Eurotel, který profituje z dřívějšího startu GSM sítě, z věrností ochotně platících business zákazníků a ze změny image u lidí v minulém roce, která byla způsobena hlavně uvedením zmiňovaného tarifu Data Nonstop. Nyní ale T-Mobile zavětřil, protože odvolání Terence Valeskiho z funkce jednatele společnosti a jeho očekáváný odchod z pozice generálního ředitele Eurotelu znamená, že Český Telecom začíná ve své dceřinné firmě úřadovat dle svého gusta. Dle zkušeností s předchozím jednáním Českého Telecomu se dá očekávat, že jeho vliv bude mít za následek pouze oslabení současné skvělé tržní pozice Eurotelu. Pro Český Telecom je důležité prosadit ADSL (ISDN snad už ani on tlačit nebude) a konkurenci v podobě CDMA nebo i GPRS, byť z domovské stáje, asi příliš podporovat nebude. Jediné, co by snad dokázalo přivést Český Telecom k racionálnímu jednání, by byl právě rychlý nárůst tržního podílu TMO na úkor ET. Takže další kolo souboje o post nejúspěšnějšího operátora začíná a Eurotel podle mého soudu poprvé není favoritem.

Sunday, 02 May 2004 19:35:00 (Central Europe Standard Time, UTC+01:00)       
Comments [5]  Mobilitky

Dva nejčastější dotazy k .NET Remotingu

V diskuzních fórech se objevuje mnoho dotazů k .NET Remotingu, ale následující dva jsou evergreenem. Těm z Vás, kdo záludnosti .Net Remotingu ještě neodhalili sami, nabízím řešení a doufám, že dotazů ve fórech ubude.:)

V .Net Frameworku 1.1 dojde při pokusu o komunikaci se vzdáleným objektem k výjimce SecurityException nebo SerializationException. V .Net Frameworku 1.0 aplikace funguje bez problémů.

.Net Framework 1.1  z bezpečnostních důvodů nepovoluje ve výchozí konfiguraci deserializaci všech typů, takže k výjimce dojde například při předání  potomka třídy MarshalByRefObject z klienta na server  nebo při registraci delegáta k události. Řešením je nastavit u objektu formatter, který provádí (de)serializaci, že povolujeme deserializaci všech typů. Úroveň deserializace vyjadřuje enumerace TypeFilterLevel a chování shodného s verzí 1.0 dosáhneme použitím hodnoty Full. Hodnotu Full přiřadíme objektu formatter (přesněji poskytovateli objektu formatter) v konfiguračním souboru nebo přímo v kódu. Nastavení úrovně full musí být provedeno na serveru a když  používáte zpětná volání (callback) nebo události, tak musíte úroveň Full nastavit i na klientovi. Nezapomeňte, že byste měli zprávy mezi klientem a serverem přenášet přes https nebo je alespoň kryptovat.

Nastavení v  konfiguračním souboru

---

Server

<configuration>

  <system.runtime.remoting>

    <application>

      <channels>

         <channel ref="http" port="7777">

      <serverProviders>

     <provider ref="wsdl" />

      <formatter ref="soap" typeFilterLevel="Full" />

      <formatter ref="binary" typeFilterLevel="Full" />

     </serverProviders>

   </channel>

</channels>

</application>

</system.runtime.remoting>

</configuration>

Klient

<configuration>

  <system.runtime.remoting>

    <application>

    <channels>

      <channel ref="http" port="0">

        <clientProviders>

        <formatter ref="binary" />

      </clientProviders>

      <serverProviders> 

         <formatter ref="binary" typeFilterLevel="Full" />

     </serverProviders>

  </channel>

  </channels>

 </application>

</system.runtime.remoting>

</configuration>

---

Nastavení v kódu

---

BinaryServerFormatterSinkProvider binProvider = new BinaryFormatterSinkProvider();
binProvider.TypeFilterLevel = TypeFilterLevel.Full;

SoapServerFormatterSinkProvider soapProvider = new SoapServerFormatterSinkProvider();
soapProvider.TypeFilterLevel = TypeFilterLevel.Full;

---

Za další otázkou se skrývá záludnější problém. Při použití http kanálu, binárního formatteru (formátovač mi nějak do pera nejde) a hostování vzdáleného objektu v IIS dostanete na klientovi občas následující výjimku.

An unhandled exception of type 'System.Runtime.Serialization. SerializationException' occurred in mscorlib.dll
Additional information: BinaryFormatter Version incompatibility. Expected Version 1.0. Received Version <nesmyslné číslo>

 

Matoucí je hlavně nesmyslné číslo na konci, které zcela evidentně nepředstavuje žádnou známou verzi formatteru a tedy nelze jednoduše nalézt pravou příčinu nepovedené deserializace. Vysvětlení je prosté - došlo k chybě na úrovni IIS a klientovi se vrátí chybové http hlášení (například HTTP/1.1 500 Internal server error), protože WWW server/vzdálený objekt není z nějakého důvodu dostupný. Bohužel formatter se snaží nalézt v této zprávě hlavičku s verzí formatteru použitého na serveru a protože ji nalézt nemůže, vyhodí matoucí hlášku, že našel nesmyslnou verzi, jejíž číslo vezme bůhvíkde.

Pastí je v .Net Remotingu více, klidně mi napište, s jakými problémy jste se setkali vy, a já připravím pokračování poradny:)

Sunday, 02 May 2004 18:08:00 (Central Europe Standard Time, UTC+01:00)       
Comments [0]  .Net Remoting

Ztracený potomek se vrací aneb vítejte v Evropě

Stejně jako Radim a další, i já jsem rád, že zítra vstoupíme do EU. Optimisté i skeptici řekli svá někdy zbytečně ostře vyhrocená pro a proti a jistě ve svém zapáleném chrlení argumentů nepřestanou, ale žádně emoce již nemohou na našem zítřejším  vstupu do EU nic změnit. I když jsem měl před referendem o vstupu do EU obavu, že český národ dá přednost taktice "máme teď své jisté a po nás potopa", nestalo se tak a přesvědčivá většina řekla vstupu do EU své ano.

Konečně snad můžeme říci, že jsou již definitivně mrtvé nereálné a sebezničující panslavistické obrozenecké koncepty, spoléhající na náruč feudálního Ruska. Tyto koncepty byly s velkou pompou oživeny komunistickými ideology a pohlaváry vrhajícími se do otcovské náruče tatíčka-cara Stalina, která se brzy proměnila v pěst knokautující naší republiku v bezvýznamného červa vydaného na pospas rozmarům senilních oligarchů v Kremlu.

Ani první republika živící sama sebe nadějí, že poloha našeho státu nás předurčuje k tomu být politickým a kulturním pojítkem  mezi Východem a Západem, mezi starým a novým světem, dlouho nevydržela. “Státy se udržují idejemi, na kterých byly založeny“, říkal Masaryk. Měl pravdu, když se ukázala iluzornost ideje pojímající republiku jako most mezi Východem a Západem, krátké období samostatnosti skončilo.

Nyní vstupujeme do nové Evropy. Do Evropy poučené kataklyzmaty dvou světových válek a odhodlané nepřipustit opět barbarství komunismu a nacismu. Do Evropy, která je snadným terčem pro kritiky, protože kompromisní hledání nové společné identity respektující rozdílnost států a řešení praktických otázek zohledňující zájmy všech zainteresovaných stran nemůže žehrající maximalisty nikdy uspokojit. Vše velké se rodí v bolestech ani Evropská Unie není výjimkou. Jsem šťastný, že se zítra naplní sen, který předchozím generacím musel připadat v existující politické konstelaci plné nočních můr nesplnitelný. Takový den si naše emoce a radost určitě zaslouží. Od tohoto roku považuji 1. Máj opět za svátek, za svátek EU.:) Užijte si ho.

Friday, 30 April 2004 17:54:00 (Central Europe Standard Time, UTC+01:00)       
Comments [23]  Ostatní

Rádio Jerevan?

Ve svém jinak zajímavém weblogu se Tomáš Kouba zamyslel nad úrovní a periodicitou česky psaných zdrojů o .Net platformě. No zamyslel, celý spot na mě působí dojmem, že ho Tomáš Kouba napsal na apríla a opožděně publikoval, ale na konci dubna tenhle spot již opravdu nepobaví.

 

Co mi tak vadí? Subjektivní dojmy vydávané za podložený názor. Třeba výčet zdrojů o .Net platformě není úplný, byly například opomenuty články na Intervalu o ASP.NET.

Nicméně to není vše, Tomáš Kouba se nám v krátkém příspěvku předvede i jako investigativní novinář, který odhalil skandál okolo nekvalitní práce správců konference Emwac, protože ti jsou údajně sponzorováni Microsoftem za to, že konference bude k něčemu vypadat. Nejde o to, že Microsoft pravděpodobně opravdu Emwacu nějakou částku za hostování platí, ale pochybuji, že pan Kouba má v ruce smlouvu mezi Microsoftem a Emwacem, ve které je napsáno, že za tučný úplatek musí Emwac provozovat konferenci v kvalitě požadované panem Koubou. Takhle vznikají fámy. Nejdříve kdosi vysloví  spekulaci, že správci EMWACu jsou za provoz konference placeni Microsoftem (proč ne?) , pak pan Kouba tuto zprávu přijme, ale stále uznává, že jde jen o dohad. Za měsíc a půl již s tou samou spekulací nakládá jako s ověřeným faktem.

Na konci příspěvku Tomáš Kouba přijme roli mudrce, který nám vysvětlí, proč je málo kvalitních článků a blogů pro .Net platformu.

„Je zajímavé, že proti Javě je úroveň a především periodicita zdrojů o technologii .NET a C# mnohem horší. Možná je to tím, že ti kteří se živí Microsoft technologiemi mají méně času. Buď je to proto, že programovat pro Microsoft je mnohem náročnější než pro Javu, nebo jsou to obecně komerčněji zaměření lidé. Psaní spotů a článků vyžaduje značnou míru entuziasmu a ten možná Microsoft oblíbencům chybí. Každý máme své priority a na penězích není nic špatného.“

Takže teď jsme se konečně o .Net vývojářích dozvěděli holou pravdu. Jen nevím, co si mám představit pod „komerčněji zaměřeným člověkem“. Asi homo novus, dle všeho pěkná svině:). .Net vývojářům chybí jakékoli nadšení, ale zato jsou to oslíci, kteří na každém kroku trousí prachy ušetřené tím, že svůj čas rozumně neinvestují do psaní článků nebo blogů, protože se nechali poučit, že stejně mají nižší úroveň než články o JAVĚ.

Ten spot nezarazil jen mě, ale třeba i Romana Pichlíka. Tohle jste myslel vážně pane Koubo?

Thursday, 29 April 2004 21:26:00 (Central Europe Standard Time, UTC+01:00)       
Comments [14]  Ostatní