Cloud as a Story - Vunvulea Radu

Lista postări despre Office interop pe Silverlight: Part 1 Part 2 Part 3 In postul precedent am povestim despre problemele pe care le putem avea când încercam sa folosim API de Office pe Silverlight. Astăzi o sa discutam despre modul în care care trebuie configurat proiectul pentru a putea sa folosim API de Office și cum putem sa executam câteva funcții de baza. Pentru a putea apela API de Office pe Silverlight este nevoie sa setam aplicația sa ruleze Out of the brower (OOB) și sa cu permisiuni elevate. Aceste setări trebuie setate pe proiectul de Silverlight care conține App.xml. Click dreapta pe proiect în tab-ul Silverlight checkbox-ul "Enable running application out of the brower" sa fie check-uit iar în setările pentru out of the brower aveti grija sa check-uit și "Require Elevated trust when running outside the browser". Pentru a putea sa accesam API de Office (COM-uri in general) din Silverlight o sa fim nevoiți sa lucram cu obiecte de tip dynamic. Crearea

Lista postări despre Office interop pe Silverlight: Part 1 Part 2 Part 3 Acesta este primul post dintr-o serie de trei sau patru posturi în care o sa discutam despre Silverlight și interop (Office interop). Dupa cum știm Silverlight suporta integrarea cu Office prin intermediul la interop, dar înainte sa ne aruncam cu capul în fata în API si sa vedem ce putem face o sa prezint ce nu putem face din Silverlight. Nu avem acces la API-ul de Office in totalitate. Chiar daca in teorie folosim COM-urile de Office nu o sa putem apela orice metoda. De exemplu din cauza modului in care o aplicație Silverlight ruleaza pe o masina, nu o sa putem face pe client new la un nou document. Dar acest lucru este cauzat direct de Silverlight, care nu ne permite sa generam fisiere pe client (in modul in care Office-ul are nevoie). O solutie la aceasta problema este crearea fisierului pe server, iar apoi sa il copiem pe client. Putem sa avem templaturi care sa le copiem pe client si prin duplicarea lor sa r

In postul precedent am povestim putin despre where . Iata o constrîngere destul de interesanta pe care o putem face: class Car<TTItem,TItem> where TItem:IItem { public TSubItem GetColor<TSubItem>(string name) where TSubItem:TItem { ... } } Ce mi-a placut este ca putem sa ne definim o constrangere care sa contina un tip care este deja generic. Nice :)

Mai mult ca sigur cu toții am folosit clauza where . Pe scurt, where este folosit când trebuie sa adaugăm o constrângere la un tip generic specificat la o clasa sau la o metoda. public class Car<TType> where TType : ICarModel {} In exemplul de mai sus o sa putem folosii tipuri generice TType doar dacă implementează interfața ICarModel . In cazul in care vrem sa specificam ca tipul generic sa fie neaparat o clasa este nevoie sa ne folosim si de cuvantul rezervat class: public class Car<TType> where TType : ICarModel, class {} In cazul acesta, TType trebuie sa fie obligatoriu sa fie o clasa (nu va putea sa fie o structura de exemplu). Pentru structuri trebuie sa folosim cuvantul rezervat struct: public class Car<TType> where TType : struct {} Dar dacă vrem sa face new de un obiect de tip generic? In cazul aceasta trebuie sa specificam ca are un constructor default în clasau de where . Din păcate doar constructorul default fără parametri se poate specifica. I

Uneori când scriem unit teste avem nevoie sa specificam anumite fișiere care sa fie copiate în directorul de unde rulează testele. Cea mai simpla variante este sa adaugăm aceste fișiere în *.testsettings (la secțiunea Deployment). Dar dacă vrem sa specificam aceste dependințe separat, pentru fiecare unit test în parte? Putem sa facem acest lucru folosindu-ne de atributul DeploymentItem . Acesta poate sa fie specificat per clasa sau metoda de unit test. Putem sa specificam ce fișier sa se copieze în output și opțional și sub ce director. [TestClass] [DeploymentItem("text.txt")] public class ATest { [TestMethod] public void M1Test() { ... } } In cazul în care vrem sa specificam un director sa fie copiat 1 la 1 în output-ul pentru teste este nevoie sa specificam doar numele la director. [TestClass] [DeploymentItem("DirNameSource","DirNameDestination")] public class ATest { [TestMethod] public void M1Test() { ... } } In exemplul de mai sus am

Într-un post anterior am prezentat pe scurt API la Azure AppFabric. http://vunvulearadu.blogspot.com/2011/07/azure-appfabric-cache-api.html Dupa cum ştim, în momentul în care punem aplicaţie web pe cloud, noţiunea de sesiune nu mai exista din cauza ca nu ştim dacă o sa ajungem la aceiaşi instanta a unui server intre doua apeluri succesive. Pentru a putea rezolva aceasta problema putem sa folosim Azure AppFabric. Dupa ce configuram Azure AppFabric trebuie sa adaugăm în web.config următoarea secţiune: <system.web> <compilation debug="true" targetFramework="4.0"> </compilation> <sessionState mode="Custom" customProvider="AppFabricCacheSessionStoreProvider" compressionEnabled="false"> <providers> <add name="AppFabricCacheSessionStoreProvider" type="Microsoft.Web.DistributedCache.DistributedCacheSessionStateStoreProvider, Microsoft.Web.DistributedCache"

Se da: o aplicatie web dezvoltata in Visual Studio 2010; un certificat care insoteste aplicatia; brower de test IE9; De fiecare data cand o rulam aplicatia o sa apara urmatorul warning: The security certificate presented by this website was not issued by a trusted certificate authority. Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server. We recommend that you close this webpage and do not continue to this website. Dupa 10 rulari deja o sa incepem sa ne saturam sa dam Continue . Ca sa scapam de acest mesaj putem sa schimba cheia din registri HKEY_USERS\<SID>\Software\Microsoft\Windows\CurrentVersion\Internet Settings:WarnonBadCertRecving cu valoarea 0. Este foarte importat sa nu uitam aceasta cheie setata pe valoarea 0 dupa ce terminam dezvoltarea. O alta varianta este sa facem disable la acest warning din: IE Tools->Internet Options->Advanced->Security->Warn about certificate address mismatch Enjoy.

Nu de mult a fost lansat CTP pentru Azure AppFabric Caching. In ultima perioada am început sa studiez API-ul acestuia mai în detaliu. O sa încerc în urmatoarele rânduri sa trec în revista API-ul acestuia si sa fac highlight la cea ce ii mai important. In primul rand este bine de stiut ca Azure AppFabric nu este totuna cu Windows Server AppFabric. Chiar daca cele doua se aseamana, acestea au assembly-uri diferite pe partea de client. Totodata nu avem posibilitatea sa facem switch intre Windows Server AppFabric si Azure AppFabric. API-ul care îl ofera Azure în acest moment nu este atât de larg, partea de notificari si regiuni înca nu este suportata în întregime. Am scris într-un post trecut modul în care trebuie sa se configureze Azure AppFabric. In momentul în care am configurat cache-ul în cloud, acesta ne pune la dispozitie sectiunea care trebuie sa adaugam în fisierul de configurare (aceasta v-a contine inclusiv token-ul de autentificare). http://vunvulearadu.blogspot.com/2011/03/out

Pornim de la următoarea problema: Avem un site în cloud. Dorim sa restricționam accesul pe baza de IP. Vrem sa excludem o anumita clasa de IP-uri. Cautînd pe google și prin blog-uri am găsit doua soluții propuse, care sa și funcționează pe Azure: IPSecurity IHttpModule 1. In prima varianta trebuie sa restricționam accesul la clasele de IP-uri din fișierul de configurare. <location path="CarWebSite"> <system.webServer> <security> <ipSecurity> <add ipAddress="123.456.0.0" subnetMask="255.255.0.0" allowed="false" /> </ipSecurity> </security> </system.webServer> </location> Mai sus am restrictionat accesul la IP-urile 123.254.0.1 pana la 123.254.255.255 pentru path-ul CarWebSite. Daca am fi pe un Windows Server 2003 acesta setare ar functiona fara nici o problema. In schimb pe Windows Azure o sa avem o mica surpriza. Din cauza ca pe IIS din

In urma cu cîteva luni aveam nevoie de un un mecanism prin intermediul căruia sa consum servicii REST din .NET. La prima strigare acest lucru este destul de simplu de făcut (de implementat), avem nevoie un obiect de tip HttpRequest. Dar am vrut mai mult de atît, doream un API simplu prin care sa pot sa fac apeluri REST. O soluție la îndemîna era sa încep implementarea unui astfel de API de la 0, cea ce am și făcut în prima faza, deoarece nu este foarte complicat (mi-a luat in jur de 12 ore pana sa ajuns la un API destul de bogat). Intre timp am început sa caut pe web ce soluții free exista și am descoperit RestSharp . Este un client pentru servicii în format REST open-source destul de robust și bine gîndit. Ce mi-a plăcut la el cel mai mult și m-a făcut sa îl folosesc este numele la clase (foarte sugestive) și ușurința cu care se poate folosii plus ca primele linii de cod pe care le-am scris pentru acest IP au funcționat din prima. Mai jos puteți sa găsit un exemplu: RestClient restCli