Vítejte na blog.vyvojar.cz Přihlásit | Registrovat | Pomoc

Jednoduché ladění WCF služeb

Nedávno jsem narazil na velice zajímavou možnost, kterou poskytuje Visual Studio 2008 vývojářům WCF aplikací.

Osobně jsem služby a klienty na této platformě debugoval “sadomaso” způsobem – služba jako Console Application 1 a klient jako Console Application 2. Jde to způsob velice nepohodlný, pracný a hlavně tupý.

Visual Studio 2008 sebou nese jednoduchou utilitu WcfSvcHost.exe, která slouží k hostování služeb a přijímá parametry:

/service:knihovna_se_sluzbou.dll /config:configuracnisoubor.config

Uveďme si modelový příklad.

1. Vytvoříme si prázdnou Solution

2. Přidáme projekt WCF knihovny

wcflibraryproject

V této knihovně vytvoříme kompletní službu – kontrakt, implementaci a konfigurační soubor.

3. Přidáme projekt pro klienta ( Console App, WinForm … )

Nejprve tento projekt musíme nastavit jako výchozí v dané Solution. Dále zvolíme Add Service Reference a ve známém dialogu dáme prohledat Solution ( Discover – Service in Solution ), kde by se měla objevit WCF knihovna:

reference

Po potvrzení OK se chvíli počkáme a všimneme si, že již v tuto chvíli Visual Studio spouští WCF knihovnu v aplikaci WcfSvcHost.exe, aby mohlo získat její metadata.

A to je celé, nyní pouze vložíme kód pro volání služby.

4. Debug

A jak nyní probíhá samotné ladění ? Jednoduše, dáme debugovat samotného klienta a Visual Studio si ještě před jeho startem spustí v debug módu i WCF knihovnu pomocí WcfSvcHost.exe Můžeme tak dát breakpointy do klienta i služby a debugovat je dohromady.

Vzorová Solution

Posted by eXavera | 0 Comments

MCP certifikace - zkušenosti

Včera jsem úspěšně zvládl zkoušku MCTS certifikátu 70-536 .NET Framework  - Application Development Foundation. V zápalu radosti a blaženosti jsme se rozhodl, že zde stručně popíši, jak a s čím jsem se na zkoušku připravoval, kde a jak jsem ji následně složil. Mělo by to posloužit zejména těm, kteří se na svůj první certifikát teprve chystají.

Příprava

Pan strýček google vám s radostí vyplivne tisíce odkazů s okruhy na příslušnou zkoušku, brzy mi však došlo, že pouhým přežvykováním stovek tříd na MSDN se toho moc nenaučím. Zavolal jsme si tedy na pomoc odbornou literaturu nejpovolanější:

70-536 .NET Framework 2.0 - Application Development Foundation Training Kit

70-536-book Najdete v ni téměř vše co ke zkoušce potřebujete. Je rozdělena do šestnácti základních kapitol, jako je např. Serialization, Reflection, Application Security apod. Ty jsou rozděleny do tří až pěti lekcí. U každé lekce je shrnutí a několik kontrolních otázek. To samé platí pro kapitoly, které jsou navíc doplněny o jakési úkoly typu "vyzkoušej v praxi". Odpovědi samozřejmě naleznete v zadní části knihy.

Okruhy jsou probírány svižně a bez zbytečných detailů, zachází se jenom tam, kde to na zkoušku potřebujete. Pokud máte o určitý okruh hlubší zájem, musíte sáhnout jinde.

Bohužel úroveň otázek na konci lekcí je nevalná. Občas mi připadalo, že vás mají spíše udržet vzhůru, než zopakovat látku. Dokonce jsem narazil na několik chyb, které na důvěře moc nepřidají.

 

Ke knize dostanete CD s elektronickou verzí knihy a hlavně s jednoduchou aplikací:

Microsoft Press Training Kit Exam Prep

training-kit 

Díky tomuto prográmku si můžete vyzkoušet, kam až vaše znalosti sahají. Nejprve máte na výběr, zda si chcete procvičit otázky z konce lekcí nebo tzv. certifikační mód, kde máte 45 otázek a časový limit. Na konci uvidíte, jak jste dopadli.

Zajímavější je studijní mód, kde vás neruší časový limit a máte možnost u každé otázky požádat o vysvětlení.

Bohužel jsem zde narazil na hodně chyb, například jsem se dozvěděl o mystické metodě "StartLowPriority" ve třídě "Thread". Vskutku zajímavé takhle balamutit uchazeče, možná je to jeden ze způsobů, jak je udržet v hladině zdravého šílenství.

Přesto prográmek hodnotím kladně, člověk narazí na pár záludností, které se vám mohou u zkoušky hodit.

Kde a jak na zkoušku

Zpočátku jsem trpěl představami, že budu muset přinejmenším do české pobočky Microsoftu a tam mě budou vyslýchat strašní o obávaní zaměstnanci. Brouzdal jsem internetem a našel jsem společnost EIITE. Stačilo vyplnit formulář a příští večer mi přišel potvrzovací e-mail. Pak nastala ta správná chvíle panikařit, že to ještě neumíte.

Zkouška

Dostavil jsem se na příslušné místo 20 minut před příslušnou dobou. Byl jsem přijat, prokázal jsem se dvěma doklady totožnosti a podepsal papír hlásající pravidla. Pak jsem zůstal v malé místnosti jen já, počítač a kamera ( kdyby vás čistě náhodou napadlo podvádět ). Otázky nebyly zdaleka tak hrozné, jak jsme si představoval. Dokonce dávaly mnohem větší smysl a vypovídací hodnotu než otázky na tréninkovém CD.

Test jsem zvládl s velkou rezervou a odešel jsem s výsledky v ruce. Samotný certifikát mi prý bude doručen do měsíce, mám prý ale spíš počítat  se dvěma. Nu což. Čas mě v tomto netlačí.

Posted by eXavera | 5 Comments

System.AddIn - Pipeline Builder

Tým tvůrců podpory addinů v  .NET 3.5  vyslyšely prosby vývojářů a pracují na automatizaci tvorby pipeline. Ti z vás kteří měli tu čest psát pipeline složitějšího kontraktu ( např. události ) jistě potvrdí že jde vesměs o přímočarou a nezáživnou práci. Pipeline Builder všechnu tuto "otročinu" udělá za vás ( zatím se jedná o CTP verzi, podpora integrace do VS 2008 ještě není ideální ).

A jak to funguje ? Stačí v Solution mít definovaný projekt kontraktu + k projektu přilinkovat assembly PipelineHints.dll. Dále můžeme v kontaktu použít různé atributy pro nadefinování jmen segmentů, událostí, výčtů apod. Následně spustíme Tools - PipelineBuilder a ten nám vygeneruje pohledy a adaptéry.

 Pipeline Builder ve Visual Studiu

Užitečné odkazy:

Posted by eXavera | 0 Comments

System.Addin - seznamte se

Už několik let píšu rozšiřitelné aplikace dosti primitivním stylem - jedna sdílená assembly mezi hostující aplikaci a addiny. Ostatně tento způsob jsem popisoval v článku C# aplikace s podporou pluginů. V průběhu času se ukázalo jako zásadní problém řešit kompatibilitu - stačí pozměnit rozhraní a všechno jde do kytek. Také bylo velice obtížné zpracovávat chyby v addinech. Naštěstí nám vývojáři .NET Frameworku 3.5 nadělili řešení podobě tzv. pipeline, která vypadá takto:

Pipeline mezi hostem a addiny

Samotná pipeline se skládá ze segmentů. Obvykle představuje každý segment jednu assembly. Pipeline také vyžaduje následující strukturu adresářů:

Struktura pipeline


Dle mého názoru se věci nejlépe vysvětlují na příkladě. Pro naše účely nám poslouží jednoduchá rozšířitelná konzolová aplikace.

Založíme si novou prázdnou Solution s názvem ExtensibleApp.

Krok 1: segment Contract

Jádrem pipeline je segment Contract. Jedná se o neverzovatelný protokol popisující komunikaci mezi hostovací aplikací a addiny. V praxi se implementuje jako rozhraní, které dědí od IContract. Dále musí být označeno atributem AddInContract. Založme si tedy nový projekt typu Class Library s názvem ExtensibleApp.Contracts. Mějme na paměti požadovanou adresářovou strukturu, takže v nastavení projektu změníme Output path na ..\output\Contracts.
Dále do projektu přidáme referenci na System.AddIn a System.AddIn.Contract. Assembly obsahuje jedno rozhraní:
using System.AddIn.Contract;
using System.AddIn.Pipeline;
namespace ExtensibleApp.Contracts
{
      [AddInContract]
      public interface IAddInContract : IContract
      {
            string OperationName { get; }
            string Operate(string value);
      }
}
Kontraktem lze přenášet pouze serializovatelné datový typy z mscorlib ( boo, int, string apod. ), výčtové typy ( buď definované v mscorlib nebo v kontraktu ) a jiné kontrakty.

Krok 2: segment HostView

Tento segment reprezentuje pohled hostující aplikace na addiny a musí se jednat o ne-sealed třídu ( popř. rozhraní ). Nemusí být obsažen ve speciální assembly a proto my ho vložíme do samotné host. aplikace. Založme tedy nový projekt typu Console Application nazvaný ExtensibleApp . V nastavení projektu upravíme Output path na ..\output a přidáme referenci na System.AddIn. Pohled host. aplikace vypadá následovně:
namespace ExtensibleApp 
{ 
      public abstract class AddIn 
      { 
            public abstract string OperationName { get; } 
            public abstract string Operate(string value); 
      } 
} 

Krok 3: segment AddInView

Vytvoříme nový projekt typu Class Library nazvaný ExtensibleApp.AddInViews a opět upravíme jeho nastavení - Output path na ..\output\AddInViews . Taky nezapomeneme přidat referenci System.AddIn. Samotný pohled addinů na hostující aplikaci se téměř shoduje s pohledem hostující aplikace na addiny. Rozdíl je v tom, že tento pohled musí být označen atributem AddInBase.
using System.AddIn.Pipeline; 
namespace ExtensibleApp.AddInViews 
{ 
      [AddInBase] 
      public abstract class AddIn 
      { 
            public abstract string OperationName { get; } 
            public abstract string Operate(string value); 
      } 
} 

Krok 4: segment HostSideAdapter

Nyní musíme nějak provázat kontrakt s našimi pohledy - to mají na starosti adaptéry, které adaptují pohled na kontrakt a naopak.
Opět založíme nový projekt typu Class Library nazvaný ExtensibleApp.HostSideAdapters. Nastavíme Output path na ..\output\HostSideAdapters a přidáme reference na System.AddIn, System.AddIn.Contract, ExtensibleApp a ExtensibleApp.Contracts ( u posledních dvou nastavíme Copy local na False ). Adaptér vypadá následovně:
using System.AddIn.Pipeline; 
using ExtensibleApp.Contracts; 
namespace ExtensibleApp.HostSideAdapters 
{ 
      [HostAdapter] 
      class AddInContractToView : AddIn 
      { 
            private IAddInContract contract; 
            private ContractHandle handle; 
            public AddInContractToView(IAddInContract contract) 
            { 
                  this.contract = contract; 
                  this.handle = new ContractHandle(contract); 
            } 
            public override string OperationName 
            { 
                  get { return this.contract.OperationName; } 
            } 
            public override string Operate(string value) 
            { 
                  return this.contract.Operate(value); 
            } 
      } 
} 

Adaptér na hostující straně musí být označen atributem HostAdapter. Třída nemusí být veřejná a v konstruktoru se očekává instance adaptovaného typu ( nejedná se o nic jiného než návrhový vzor Adapter Wink ).

Krok 5: segment AddInSideAdapter

Založíme nový projekt typu Class Library nazvaný ExtensibleApp.AddInSideAdapters. Nastavíme Output path na ..\output\AddInSideAdapters a přidáme reference na System.AddIn, System.AddIn.Contract, ExtensibleApp.AddInViews a ExtensibleApp.Contracts ( u posledních dvou nastavíme Copy local na False ). Adaptér vypadá následovně:
using System.AddIn.Pipeline; 
using ExtensibleApp.AddInViews; 
using ExtensibleApp.Contracts; 
namespace ExtensibleApp.AddInSideAdapters 
{ 
      [AddInAdapter] 
      class AddInViewToContract : ContractBase, IAddInContract 
      { 
            private AddIn view; 
            public AddInViewToContract(AddIn view) 
            { 
                  this.view = view; 
            } 
            public string OperationName 
            { 
                  get { return this.view.OperationName; } 
            } 
            public string Operate(string value) 
            { 
                  return this.view.Operate(value); 
            } 
      } 
} 

Tato třída označená atributem AddInAdapter mimo jiné dědí od třídy ContractBase (což je výchozí implementaci rozhraní IContract ).

Řekli jsem si, že adaptér adaptuje kontrakt na pohled a naopak. Z této činnosti vyplývá, že pávě díky adaptérům máme k dispozici volné ruce při změnách v hostující aplikaci nebo addinech - pokud se změní kontrakt, stačí upravit adaptér a druhé strany se to vůbec nedotkne. O tom ale někdy jindy.
Máme tedy segment kontraktu a dva pohledy na něj z každé strany. Máme adaptéry které nám slepují celou pipeline. Zbývá tedy vytvořit hostující aplikaci a nějaké addiny. 

Krok 6: segment AddIn

Vytvoříme nový projekt typu Class Library nazvaný AddIn1 a nastavíme Ouput path na ..\output\AddIns\Addin1. Dále přidáme referenci na ExtensibleApp.AddInViews ( Copy local na False ) a System.AddIn. AddIn je odvozená třída od pohledu:

using ExtensibleApp.AddInViews; 
namespace ToUpper 
{ 
      [System.AddIn.AddIn("ToUpper add-in", Version = "1.0.0.0")] 
      public class ToUpper : AddIn 
      { 
            public override string OperationName 
            { 
                  get { return "vsechny pismena velka"; } 
            } 
            public override string Operate(string value) 
            { 
                  return value.ToUpper(); 
            } 
      } 
}


Třída musí být označena atributem AddIn, který obsahuje vlastnosti jako název rozšíření, verze, popis apod.

Krok 7: segment Host

V této chvíli je pipeline vlastně hotova. Projekt hostovací aplikace ExtensibleApp jsme již vytvořili v kroku 2, takže nyní jenom doplníme kód do metody Main.
Myšlenka aplikace je taková, že uživatel napíše libovolný text a ten bude předán každému addinu ke zpracování.

Console.WriteLine("Zadejte text ktery bude zpracovan kazdym modulem:"); 
string input = Console.ReadLine(); 
Console.WriteLine();

.NET Framework si uchovává informace o pipeline v cache a jako první krok v práci s addiny bychom měli cache aktualizovat:

AddInStore.Update(PipelineStoreLocation.ApplicationBase);

Najdeme všechny addiny, které vyhovují HostSideView:

IList<AddInToken> tokens = AddInStore.FindAddIns(typeof(AddIn), PipelineStoreLocation.ApplicationBase); 

V této chvíli máme kolekci tzv. tokenů, což jsou struktury popisující addiny ( tzn. že se nejedná o aktivní addiny ). Všechny v cyklu projdeme a aktivujeme je  metodou Activate. Pak máme k dispozici samotné instance addinů:

foreach (AddInToken token in tokens) 
{ 
      Console.WriteLine("Rozsireni: {0}, verze: {1}", token.Name, token.Version); 
      AddIn addin = token.Activate<AddIn>(AddInSecurityLevel.Internet); 
      Console.WriteLine("Operace: {0}", addin.OperationName); 
      Console.WriteLine("Vystup: {0}", addin.Operate(input)); 
      Console.WriteLine(); 
}

V této konfiguraci se každý addin načte do vlastní AppDomain.

Celý tento příklad je k dispozici v příloze. Jako základní pro pochopení doporučuji .NET Application Extensibility - Part 1 a .NET Application Extensibility - Part 2.

Posted by eXavera | 1 Comments

Attachment(s): ExtensibleApp.zip
 
Vyvojar.cz na prodej!