Environment.NewLine or "\r\n"

Ma uitam zilele astea peste un cod si am vazut de mai multe ori cod de genul acesta:

string v2 = v1 + "\n";

Scopul la acest cod este de a trece pe o linie noua. Desi functioneaza si este folosit de catre foarte multi dezvoltatori nu este cea mai buna solutie. Pentru a trece la o linie noua cei de la Microsoft au adaugat o propietatea Environment.NewLine. De fapt aceasta este o constanta ce ne returneaza "\r\n" pe Windows.
IL care se genereaza face un call la System.Environment::get_NewLine() care in spate are urmatoarea implementare pentru Windows:

.method public hidebysig specialname static string get_NewLine() cil managed

{

.maxstack 8

L_0000: ldstr "\r\n"

L_0005: ret

}

In functie de platforma NewLine poate sa difere, o implementare pentru UNIX ar contine doar "\n". Desii Environment.NewLine este mult mai clar in cod, nu cred ca se va renunta la "\r\n" deoarece nimeni nu va uita ce inseamna "\r" sau "\n". Pana se va ajunge sa se scrie aplicatii .NET care sa ruleze by default pe mai multe sisteme de operare o sa mai treaca ceva vreme.
Eu prefer si incerc sa folosesc Environment.NewLine, voi ce folositi?

Update:
Un caz cand nu se poate folosii NewLine este cand vrem sa declaram o constanta care sa contina si NewLine:
const string Text = "Hello" + Environment.NewLine + "Word!";
Din cauza ca NewLine este o propietate si nu o contanta linia de cod scrisa mai sus o sa crape.
Daca lucram cu un TextBox o sa ne trezim ca urmatoarea linie de cod nu ne da rezultatul pe care l-am astepta:

errorTextBox.Text = "Error: \n\n\";

Problema este ca TextBox-ul necesita si un CRLF, nu doar LF. In acest caz avem posibilitati:
errorTextBox.Text = "Error: \r\n\r\n\";
sau
errorTextBox.Text = "Error: "+ Environment.NewLine + Environment.NewLine ;

Read More

AppFabric Cache - more than one writers in the same time

Intr-un post anterior am discutat despre AppFabric Cache, care are la baza mecanismul de DataCache pentru Windows Cache Server. Intr-un mediu in care avem mai multe masini care scriu pe acelasi cache trebuie avuta grija destul de mare la urmatorul caz:

In acelasi timp 2 sau mai multe masini doresc sa scrie acelasi element in cache( aceiasi cheie).

Cuvantul cheie la aceasta problema este "IN ACELASI TIMP". In mod normal am avea urmatoarea implementare pentru a scrie un obiect in cache:

DataCacheFactory cache = new DataCacheFactory();

cache.Put(key,value);

Totul ar functiona fara nici o problema pana cand 2 sau mai multe instante ar incerca sa scrie in acelasi timp un element cu aceiasi key in cache. In acest caz se arunca o exceptie de tip DataCacheException, cu error codul setat DataCacheErrorCode.RetryLater.
Pentru a rezolva aceasta problema avem doua solutii, in functie de cat de probabil e sa apara un astfel de caz putem sa folosim una din solutii, sau o combinatie din cele doua.
Prima solutie ar fi sa me folosim de mecanismul de lock care exista pentru cache.

DataCacheLockHandle lockHandle;

var value = cache.GetAndLock(key, TimeSpan.FromSeconds(1), out lockHandle, true);

cache.PutAndUnlock(key, value, lockHandle);

Avantajul la aceasta solutie este ca inainte sa se faca scrierea se face un lock explicit pe obiectul din cache, dar trebuie avut grija ca fiecare aplicatie care foloseste cache-ul sa foloseasca metode care fac lock - in caz contrat obiectul poate sa fie accesat chiar daca s-a facut lock pe acesta. Un alt dezantaj la aceasta solutie este ca trebuie facute doua requesturi la server. Unul care face GET si altul care face PUT si totodata in cazul in care se intampla ceva intre GET si PUT obiectul din cache poate sa ramana blocat din cauza lock-ului pe care il facem( trebuie sa ne implementam un mecanism de fallback.
Urmatoarea solutie pe care o propun este mult mai primitiva, dar care conserva atat conexiunea la internet cat si durata cat timp obiectul este blocat.

int retrys=5;
while(true)
{
     try
     {
          cache.Put(key,value)
     }
     catch(DataCacheException ex)
     {
          if(ex.ErrorCode == DataCacheErrorCode.Retrylater)
          {
               if(retrys <= 0)

               {

                     throw;

               }

               retrys--;

               continue;
          }

          throw;

     }
}

In cazul in care acest caz nu o sa apara foarte des as alege a doua varianta. Este mult mai simpla si mai sigura. Cand folosim a doua varianta trebuie sa avem grija daca exista si alte aplicatii care acceseaza cache-ul nostru - toti consumatorii trebuie sa foloseasca mecanismul de lock, deoarece altfel nu ar avea nici o valoare modul in care scrim noi in cache.

Read More

Convert a stream to a byte array

De cate ori nu v-ati lovit de cerinta urmatoare:

Sa se converteasca un stream intr-un sir de bytes.

Am vazut diferite implementari la aceasta solutie. Cea mai comuna este cea in care se itereaza prin stream.

byte[] bytes = new byte[10000];
int temp;
int offset;
while ((temp = ms.Read(bytes, offset, bytes.Length - offset)) > 0)
{
     offset += temp;
}

Aceasta solutie o sa functioneze, dar putem sa ne folosim si de alte functii, care sa simplifice putin codul si sa eliminam sansele ca un bug sa apara.

O alta varianta este sa folosim metoda GetBuffer. Aceasta ne returneaza sirul de bytes din care a fost creat streamul. Trebuie avut grija la doua lucruri aici:

1. nu se face o copie a sirului de bytes
2. lungimea sirului care ne este returnat nu reprezinta lungimea reala a streamului. De exemplu daca avem un stream de 10 bytes si apelam GetBuffer, o sa ne fie returnat un sir de lungime 256 din care 246 de elemente nu sunt folosite.

byte[] bytes = ms.GetBuffer();

Ultima solutie pe care o propun, este sa apelam metoda ToArray(). Prin acest mod o sa ne fie returnat un sir de lungime egala cu numarul de bytes din stream si totodata se genereaza o copie a sirului original. Nu trebuie sa ne facem griji ce se intampla daca continutul stream-ului se modifica. Trebuie stiut ca nu conteaza daca din stream s-a facut citire sau nu, ToArray() ne va returna tot sirul de bytes, indiferent de pozitia cursorului.

MemoryStream ms = new MemoryStream(new byte[]{0,1,2,3,4});
var toArray1 = ms.GeArray(); // Lungime sir returnat = 5
ms.ReadByte()
var toArray2 = ms.GeArray(); // Lungime sir tot returnat = 5

Enjoy!

Read More

Hackathon - Cluj-Napoca, 11.12.2011

In acest weekend in Cluj-Napoca a avut loc Hackathon organizat de catre Microsoft Student Partents.
Am participat la acest eveniment ca si membru din juriu. La finalul celor 24 de ore, cele 14 echipe care s-au inscris in concus au  avut niste aplicatii foarte reusite. Ne-a fost destul de greu sa alegem echipele castitoare.
Locul intai a fost ocupat de echipa DOTDOTDOT cu aplicatia TweetThePlace.

Aplicaţie care permite să laşi mesaje (şi poze) într-un anumit Place. Nu poţi vedea/posta un mesaj dacă nu te aflii în apropierea Place-ului respectiv. Suportă şi live stream folosind push notification astfel încăt dacă te aflii lâncă un Place şi se postează un mesaj la acel Place, eşti notificat. 

Vreau sa felicit toate echipele pentru ca au reusit in 24 de ore sa scrie niste aplicatii formidabile. Sper sa vad o parte din aceste aplicatii pe Marketplace.
Poze de la acest eveniment: http://www.facebook.com/media/set/?set=a.288186067889752.63330.148534875188206&type=3

Read More

Exchange Web Service - query problems

Exista mai multe versiuni de Exchange Server, majoritatea serverelor care exista la ora actuala sunt 2007 SP1 si 2010. Daca vrem sa scriem o aplicatie care acceseze direct contul de Exchange puteti sa folosim un client care consuma serviciile expuse de acest server precum EWS - Exchange Web Service. Aceasta este doar un assembly pe care trebuie sa il adaugam la proiect. Pregatesc in aceasta luna mai multe tutoriale despre EWS. In postul de azi vreau doar sa subliniez o problema pe care EWS o are. O sa vorbim mai in detaliu cu alta ocazie despre cum sa il folosim.
Exchange Server 2010 a adus cateva schimbari la nivelul entitatiilor care exista. De exemplu pe 2010 un contact poate sa aibe atasata o poza sau modul in care sunt grupate contactele difera fata de 2007. Din pacate EWS ne aduce datele in functie de versiune de Exchange pe care o accesam.
Un exemplu destul de bun, pentru a arata problema care o are EWS este cand vrem sa aducem lista de contactele a unui account. O sa ne trezim ca versiunea 2007 SP1 ne aduce obiecte de tip ExpandGroupResult, pe cand 2010 ne aduce obiecte de tip GroupMember.
Aceste probleme ma sperie, nu neaparat ca trebuie sa scriu un IF in plus, nu ar fi nici o problema, dar ce o sa ne facem cand apara urmatoarea versiunea de Exchange? Cand o sa dorim sa ne conectam la Exchange Server 20xx o sa ne trezim ca aplicatia crapa, deoarece rezultatele pe care il primim difera. Notiunea de backward compatible nu exista in acest caz si nici notiunea ca o metoda ar trebuii sa returneze un singur tip de data sau macar datele returnate sa aibe o interfata comuna, daca nu un base class.
Principala problema asa cum o vad eu vine de la libraria EWS. Chiar daca ea primeste de la server date de tipuri diferite, ar trebuii sa expuna consumatorului date de aceleasi tip.
Nu stiu ce schimbari o sa aduca urmatoarea versiune de Exchange, dar mentenanta pe aplicatiile care folosesc EWS nu o sa fie tocmai atat de placuta.

Read More

WTF - YomiGivenName, YomiSurname

In ultimu timp lucrez de mult cu serverul de Exchange. Astazi lucram cu un obiect de tip Contact si am descoperit doua propietati cu nume destul de interesant.

• string YomiGivenName { get; }
• string YomiSurname { get; }

In lista de propietati deja aveam GivenName si Surname. Denumirea este destul de interesanta. Am cautat pe msdn, dar ca de obicei descrierea este destul de vaga:

Gets the Yomi given name (first name) of the contact - sursa

Dar tot nu am inteles de la ce vine Yomi. Am cautat si pe google mai multe informatii si iata ce explicatie am gasit:

Modul in care caracterele asiatice( chinezesti) sunt citite - din punct de vedere fonetic.

Primul rezultat returnat de google a fost de pe wikipedia si era:

Yomi (黄泉?), the Japanese word for the underworld in which horrible creatures guard the exits; according to Shinto mythology as related in Kojiki, this is where the dead go to dwell and apparently rot indefinitely - sursa

Read More

EF 4.xx and storage procedure

In EF 4.xx operatiile de tip CRUD sutn foarte usor de executat. Dar ce se intampla daca avem nevoie sa executam o procedura stocata. De exemplu dorim sa populam un tabel, iar pentru acest lucru trebuie sa rulam o proceduta stocata.
Pentru acest lucru avem doua posibitati.
Prima din ele este sa ne cream un obiect de tip SqlQuery care poate sa contina orice comanda sql, iar apoi sa il executam.

DataContext.Database
      .SqlQuery<int>("EXEC PopulateTable @param1 @param2",
            new SqlParameter("param1", "100"),
            new SqlParameter("param2", "1/12/2011"));

Aceasta modalitate este perfecta cand stocata/comanda pe care o executam ne returneaza date. Cand folosim aceasta comanda, data context stie ca datele au fost modificate.
In cazul in care comanda pe care o executam nu ne returneaza valori si nu ne intereaza ca data contextul sa fie aware ca datele au fost modificate putem sa folosim comanda

ExecuteSqlCommand.DataContext.Database
      .ExecuteSqlCommand("EXEC PopulateTable @param1 @param2",
            new SqlParameter("param1", "100"),
            new SqlParameter("param2", "1/12/2011"));

Data contextul o sa stie de modificari doar cand o facem reload la date.
Daca folosim EF 4.xx si Code-First aceasta este singura posibilitate sa executam proceduri stocate.

Read More