Melborp.EE

Nipp: Muuda sisu otse TFS 2010 konfliktihalduse aknast

Tue, 20 Sep 2011 23:50:00 +0100

Kuigi TFS11 ja VS11 Previre versioonid on juba uksevahelt välja pugemas ning uue TFS11 –ga kaasas olev merge ja diff (eesti keeles “ühendus ja võrdlus vahend”?) vahend on nagu öö ja päev, kasutab suur hulk arendajaid jätkuvalt TFS2010 –t ning loodetavasti järgnev nipp on kasulik. Mina ise avastasin selle enda jaoks alles hiljuti ja see natukene punastama panev, aga ma mitte kunagi ei mõelnud, et konfliktihaldus vahend võimaldab muudatusi otse teha tulemuses (kuigi see tundub nüüd täiesti loogiline ja iseenesest mõistetav).

Kontekst

Kõigepealt tuleb muidugi kontekst paika panna. Oletame, et ma soovin oma muudatusi koodihaldusesse panna ja selle tegevuse peale ütleb Team Explorer Visual Studio’s, et ei saa, konflikt on. Keegi teine on samasid ridasid näppinud, mis mina. Üleval olev pilt illustreerib teadet.

Nipp

Seejärel lähen lähen ma “Ootel olevad muudatused” aknasse ning provin konflikte lahendada.

Ainukene võimalik variant on konflikti lahendamiseks kasutada “Merge” vahendit.

Avaneb vahend kolme koodifaili aknaga, millest vasakul on serveris olev versioon, paremal on minu versioon ja all on konflikti lahenduse tulemus (pilt all).

Nüüd aktsepteeritav lahendus sõltub muidugi olukorrast – vahest on sobiv see mis on vasakul, vahest see mis on paremal ja vahest mõlemad. Vahest on sobiv kombinatsioon vasakust ja paremast, aga mitte täies mahus. Oletame, et ma soovin esimest rida vasakult ja esimest rida paremalt. Sellisel juhul tegin mina tavaliselt nii – aktsepteerisin mõlemat, lahendasin konflikti ja ennem koodi sisse panemist läksin koodifaili kallale ning parandasin vead.

Antud nipp pakub elegantsema lahenduse.

NIPP! Ma aktsepteerin mõlemat lahendust, ning seejärel muudan koodi sobivaks alumises koodifaili aknas. Alumise koodifaili akna sisu on muudetav!

Väga lihtne lahendus ning võimalik, et enamus TFS-I koodihaldusega töötavaid arendajaid teavad seda, aga minu jaoks oli üllatus. Ma varem selle peale ei tulnud ja ometi ma peaks teadma üht-teist TFS-st.

Edu!

VS11, TFS11 Preview!

Mon, 19 Sep 2011 23:53:00 +0100

Eelmisel nädalal BUILD 2011 sündmusel avalikustas Microsoft palju uut informatsiooni, millest minu jaoks kõige põnevam on seotud Visual Studio 11 ja Team Foundation Server 11 –ga.

Nüüdseks on alla tõmmatav kõigile ka Preview versioon TFS11 –st ja Visual Studio 11 –st ning Brian Harry blogil oleva koodiga oli võimalik registreerida end ka majutatud TFS11 Preview liikmeks ning käed külge panna majutatud TFS11 –le.

Liitu majutatud TFS11 teenusega või tõmba alla VS11/TFS11 ning proovi oma keskkonnas

Järgnevalt pakuksin hunniku viiteid, et lugeja saaks alustada tutvumist VS11 ja TFS11 –ga.

Brian Harry kirjutised tänase hetkeni (19.09.2011)

Videod BUILD 2011 sündmuselt

Edu!

Nipp: AsseblyInfo, AssemblyVersion, AssemblyFileVersion

Wed, 31 Aug 2011 02:53:00 +0100

Järgnev nipp on kasulik rohkem toote arenduses, kui mujal – vähemalt ei ole see suuremat tähelepanu tüüpilisi tähtajalisi projekte arendades minu poolt saanud.

Ma usun, et kõik .NET-i arendajad on teadlikud failist nimega AssemlbyInfo.*, mis iga projektiga kaasa tuleb, ja milles erinevad projekti kirjeldused, omadused, allkirjastamine jne kirja saab panna nii, et need kaasa ja arvesse võetaks kompileeritud programmi faili genereerimisel (binaar fail nagu .dll või siis käivitatav fail nagu .exe).

Attribuudid – AssemblyVersion ja AssemblyFileVersion

Antud failis on alati kirjas kaks järgnevat attribuuti (näidis):

[assembly: AssemblyVersion("1.7.0.0")]
[assembly: AssemblyFileVersion("1.7.5.5")]

AssemblyVersion – kompileeritud programmi koodi versioon, mida kasutatakse ühest programmikoodikogust (binaar failist) teisele programmikoodikogule (binaar failile) viitamisel ning sõltuvuse kirjeldamisel (illustratsioon konfiguratsiooni failist, kus on defineeritud custom sektsioon)
```
<section 
name="demo" 
type="TKInc.Demo.DemoSection, TKInc.Demo, Version=1.7.0.0, Culture=neutral, PublicKeyToken=88e86yy70c7749na" 
/>
```
AssemblyFileVersion – faili versioon nähtav kui vaadata faili omadusi (järgneval pildil – File Version ja Product Version)

Attribuutide väärtused toote arenduses

Toote arenduses, milles ma ise igapäevaselt osalen on meil vaja toetada paraleelselt mitmeid erinevaid versioone, mis võivad olla kasutuses kliendi keskkonnas (k.a. minor (2.1.0.0), service pack (2.1.2.2) kui ka hotfix (2.1.2.2) versioonid).

Oletame, et kliendil 1 on toote versioon 2.1.0.0.
Oletame, et kliendil 2 on toote versioon 2.2.0.0.
Oletame, et kliendil 3 on toote versioon 2.1.2.2.

Klient 1 ja 3 antud juhul, omavad sama assembly versiooni, aga erinevat faili versiooni.

Meile, kui ettevõttele on tähtis teada täpselt, mis versioon koodist jookseb kliendi keskkonnas. Samas, kuna toode on keerukas, arendus, deployment ja uuendamine tuleks teha võimalikult valutuks ja lihtsaks ning just siin tuleb appi nende kahe attribuudi nutikas ärakasutus.

1. Nimelt võimaldab AssemblyFileVersion versioneerida ja pidada arvet täpse deploytud kompileeritud koodi versiooni üle, kuna see ei mõjuta ühtegi teist binaarfaili, mis sõltub ja viitab deploytud binaar failist.

2. AssemlbyVersion-i uuendamine ainult major või (major ja minor) versiooni numbrite muutmisel lihtsustab arendust ja deploymist, kuna ei ole vaja uuendada kõiki viiteid antud binaar failile. Kui tegu on sama assembly versiooniga, ja muutunud ainult faili versioon, siis viiteid ei ole vaja uuendada.

Võtke Assembly versiooni kui lubadust teistele sõltuvatele osapooltele, et liides klassidele/meetoditele jääb samaks.

Tähelepanu! Selleks, et end mitte orki ajada ning lubatud kasu lõigata, tuleks järgida mõnda lihtsat reeglit.

Esiteks, kui muutub ainult faili versioon, siis ei tohi lõhkuda ühtegi meetodi/klassi liidest, või saate te üllatuse osaliseks, kus mõndade meetodite välja kutsumine enam ei toimi.

Teiseks, kui te otsustate siiski assembly versiooni mitte muuta, aga lõhute mõne liidese, siis võibolla peate te samaaegselt uuendama mitut sõltuvat ja muudatusest mõjutatud assemblyt, et rakendus saaks edasi toimida. Igatahes on see riskantsem ja mahukam ettevõtmine.

Ma toon välja väärtused toote arendusest, kuna selles valdkonnas tegelen ma ise hetkel ja just siin on mulle need silma hakanud. Teil on aga vaba valik leida väärtust ka mujalt, ja kui leiate, siis palun jagage ka minuga kommentaaride või meili näol.

Näide – .NET v4

Juba praegu on .NET v4 –le tehtud mitmeid uuendusi ja faili versioon on mitmeid kordi muutunud, aga kui te vaatate näiteks machine.config faili v4.0 –le, siis assembly versioon jäänud samaks. See tagab lihtsama hallatavuse, ja samas teab alati, mis versioon koodist on kasutusel.

Samal ajal details mscorlib.dll minu arendusmasinas.

Edu!

Microsoft otsib Partnertudengeid

Wed, 31 Aug 2011 01:13:51 +0100

Järjekordselt on kätte jõudnud aeg, mil Microsoft Eestis on alustanud partnertudengite otsingut tehnoloogia-, disaini- ja turundusvaldkonnas. See traditsioon sai alguse juba üle viie aasta tagasi ning selle aja jooksul on mitmed kümned eesti tudengid saanud võimaluse osaleda aktiivselt tehnoloogia ürituste organiseerimisel, nautida uusimate tehnoloogiate võlusid ning jagada teadmisi ja saada kogemusi esinedes, rääkides, kirjutades, väideldes, vaieldes erinevatel tehnoloogia teemadel.

Miks kandideerida? (MS-i lehelt)

Rahvusvaheliselt tunnustatud partnertudengi staatus
Tasuta ligipääs kogu Microsofti tarkvarale
Hulgaliselt koolitusvõimalusi (tehnoloogiaraamatud, e-õppe & klassikoolitused)
Võimalus saada Microsofti sertifitseeritud professionaaliks (MCP)
Kuulumine superlahedasse Eesti tehnoloogiahuviliste tudengite eliitgruppi
Võimalus osaleda põhjamaade ja Baltikumi MSP-de kokkutulekul Rootsis
Tasuta reis aastaauhinna võitjatele
Microsoft Eesti esinduse juhi soovituskiri tulevasele töökohale kandideerimiseks
Hindamatu kogemus Microsofti meeskonda kuulumisest

Ma ei saa teie eest otsustada ja ma ei tea, mida teie väärtustate, aga ma olin üks MSP’de eellane ning need kogemused ja kontaktid, mis ma sain ning lõin ülikooli ajal esinedes, Microsofti meeskonnaga koos töötades, reisides, ennast (ja vahest ka teisi) koolitades, uue tarkvaraga tutvudes, on mul siiamaani alles, ma hindan neid kõrgelt ja on jätkuvalt värskelt meeles. Osalt just tänu sellele kogemusele ja osalusele olen ma jõudnud töötada Microsoftis, olnud MCT ja treenija ning olen hetkel MVP. Mul on alati heameel näha ja lobiseda sel ajal loodud tuttavate ja sõpradega Eestist, Euroopast, USA’st ja mujalt maailmast ning ühe mu esimese kontaktiga Microsoftist, Emanuele Ognissantiga õnnestub mul siiamaani iga aastaselt kohtuda ning väike lõuna või õhtusöök teha ja minevikust, olevikust kui ka tulevikust rääkida :)

Rohkemat infot ning avalduse vormi leiad Microsofti lehelt.

Hetke ja eelmiste MSP-dega saate ühendust võtta ning kandideerimise nippe küsida Facebooki saidi vahendusel ;)

Head kandideerimist, aega on vaid 2-se Oktoobrini!

Uus TFS Power Tools – august 2011

Sat, 20 Aug 2011 01:23:00 +0100

Eile lasi välja Microsoft Visual Studio ALM–i meeskond järgmise versiooni TFS-i power toolidest. Seekordne versioon toob nii mõnegi kasuliku uuenduse, millest nii mõnedki TFS-i kasutajad puudust on tundnud.

Installeerimine

Esimene uuendus on see, et enam ei pea eelmist versiooni TFS Power Toolidest eemaldama, selleks et saaks uut versiooni installeerida, vaid installer uuendab uue versiooni peale ja eemaldab vana ennem. Küll võib juhtuda et peate oma süsteemi taaskäivitama (või siis piisab windows exploreri restardist?)

Tööülesannete (Workitem) otsing

Teine nendest on Power Toolidega välja lastav "Workitem search”, mis teeb täis sõne otsingu tööülesannete (workitem) pealt. Sarnane laiendus on muidu eraldi codeplexi projekti kaudu kättesaadav olnud, aga nüüd plaanitakse see funktsionaalsus integreerida järgmise Visual Studio/TFS-i tootesse ja Power Tool võimaldab uue funktsionaalsuse juba varakult kasutajateni tuua. Selleks, et otsingu box nähtavale saada tuleb sisse lülitada Visual Studio’s käsuriba nimega “Workitem Tracking” (all oleval pildil) ning seejärel peaks nägema punases kastis olevat käsuriba Visual Studio’s (punases kastis olevad nupud/otsingu kast).

Parem klõps Visual Studio toolbaril ning seejärel avaneb loetelu erinevate vahendite jaoks, kust saab järgnevat valida.

Visual Studio’s otsingu toolbar

Muudatuste tagasi võtmine (changeset rollback)

Kolmas uus funktsionaalsus on muudatuste rollbackimise (tagasi võtmise) kasutajaliides. Antud funktsionaalsus on olnud käsurealt kättesaadav alates TFS 2010-st, aga kasutajaliidest ei ole varem olnud.

Esimene valik. Kasutaja liides näeb välja järgmine, kui vajutada “Rollback …” kausta peal Source Control Exploreris.

See liides pakub võimalusi tagasivõtta üks muudatus, või rida muudatusi.

Teine võimalus on vajutada muudatuste ajaloos muudatuse peal parem klõps ja rollback (all olev pilt).

Tähelepanu! Pange tähele, et rollback on muudatus, mis tehakse esialgu teie oma kettal ning te peate muudatuse sisse checkima (pending changes) alt, et see TFS-i serveris realiseeruks (all olev pilt illustreerib). Seejärel kajastub see kui eraldi checkin muudatuste ajaloos. See võimaldab ka rollback-i rollbackida ;)

Need funktsionaalsused olid mõlemad ka kõrgelt hinnatud Visual Studio uservoice foorumis.

Head TFS-i kui ka uue Power Tool’i kasutamist!

Kasulikud viited: Visual Studio ALM - 31072011

Sun, 31 Jul 2011 23:42:00 +0100

Seekordses postitused sooviksin jagada viimase aja kasulikumaid viiteid Visual Studio ALM valdkonnas. Ma proovin niisuguse viitekogu kokku panna umbes üks kord kuus eelneva kuu kohta.

Team System Café – on lehekülg, mida oled soovinud blogida/mainida juba pikka aega, aga pole veel jõudnud. Igatahes agregeerib see lehekülg suure koguse informatsiooni Visual Studio ALM-I uudiste, how-to’de jt. kohta. Lisaks on lehel hunnik resursse presentatsiooni materjalide näol.

Visual Studio ALM Community Blog Aggregator – nagu nimetus ise ütleb, on tegu agregaatoriga Visual Studio ALM blogi maastikult, kusjuures ühendab ta nii MVP’d, Visual Studio ALM Rangerid ja Visual Studio tootegrupi blogid. Agregaator võimaldab ka full-text otsingut üle blogide.

Brian Harry seeria teemal “Visual Studio ALM vNext” – antud seeria algust on paljud Visual Studio ALM MVP’d juba pikka aega oodanud. Miks? Kuna enne kui Microsoft ei ole avalikustanud informatsiooni järgmise versiooni muudatuste, uuenduste, omaduste kohta, ei tohi MVP’d sellest ka kirjutada. See on osa NDA’st mille kõik MVP’d alla kirjutavad. Igatahes Brian Harry on alustanud seeriat, kus ta räägib järgmise Visual Studio ALM versiooni erinevatest aspektidest ja soovitan kõikidel huvitatutel lugema minna. Hetkel küll alles 2 postitust, aga rohkem peaks olema teel.

Visual Studio ALM video viidete kogu – usin Microsofti töötaja nimega Esther Fan (ei ole kindel, kas see on õige nimi) on postitanud loetelu erinevatest “how do” videotest.

Visual Studio ALM Rangerid on jõudnud MSDN-I

Projektide loetelu

VS ALM Rangerite materjal Build’i kohandamise võimalustest (Build Customization Guidance) Visual Studio ALM’s. Codeplexi lehelt:

Practical guidance and tooling to simplify the customization of Team Foundation Build
Practical guidance to use Team Foundation Build process templates to automate build and non-build scenarios in Microsoft environments
Practical guidance to enable simple and flexible deployment of applications and their data stores
Practical guidance for Activities to empower developers and build engineers
Quality hands-on labs that complement the guidance and effectively guide the user through the features
Visualization of the guidance using quick reference posters

Kujunda järgmist Visual Studio’t ja TFS’i

Thu, 14 Jul 2011 23:55:00 +0100

Visual Studio ja Visual Studio rakenduse elutsükli haldamise (vot see on keerukas eesti keeles, mõtlen muidugi „Application Lifecycle Management/ALM“) vahendite kohta tagasiside kogumiseks on Microsoftil juba paras ports erinevaid kanaleid nagu connect (bugide kogumiseks kasutajatelt), MSDN foorumid (küsimustele vastamiseks, informatsiooni, jne. jagamiseks), Visual Studio ALM MVP’d (ja nende vastavad kanalid), tootegruppide blogid, mõned välised foorumid (nagu stackexchange) jt. Nüüd on sellesse perekonda lisandunud uus kanal nimega uservoice.

Uservoice võimaldab ettevõtetel koguda tagasisidet toote funktsionaalsuste ja omaduste kohta, organiseerida helpdeski (kasutaja tuge), hallata probleeme ja küsimusi. Ise pole seda varem kasutanud, seega suunaks lugeja targema uservoice lehekülje peale.

Microsoft on hetkel loonud selle keskkonna eesmärgiga koguda kasutajatelt ideid ja tagasisidet võimalike uute funktsionaalsuste kohta. Kasutaja saab sisestada oma ideid, mida järgmine versioon Visual Studiost või TFS-st (ehk siis hetkel arenduses olev versioon) võiks endas sisaldada (või mida võiks muuta) ning seejärel saavad kõik külastajad hääletada teda huvitavate ideede ja muudatuste poolt.

Niimoodi kogub Microsoft tagasisidet toote kasutajatelt ning kõige suuremate häältega (ehk siis kasutajaid/kliente kõige rohkem huvitav idee) võib jõuda ka reaalselt järgmisesse toote versiooni. Pange tähele, et kasutajatel on limiteeritud kogus hääli (10). Kasutage neid targalt!

Ideid saate postitada ja hääletada järgnevatelt saitidelt:

Head ideede genereerimist ja hääletamist!

[Lisa] On olemas ka Silverlighti uservoice - http://dotnet.uservoice.com (vähemalt hetkel kasutatakse seda silverlighti jaoks)

[UUENDUS - 16.07.2011] Visual Studio ALM uservoice sait on kokku viidud Visual Studio uservoice saidiga

Tagasi blogimaastikul uue energiaga

Tue, 12 Jul 2011 01:58:00 +0100

Päris pikk aeg on mõõdas viimasest postitusest – veidi rohkem kui 6 kuud. Niisuguse pika vahe tingis alguses pidev reisimine ja seejärel suurem töö kogus, mis reisimisega tekkis. Reisimisest lähemalt – detsembris sai Eestis käidud nii loengut kui ka jõule pidamas, seejärel kuu aega Tais seljakottidega reisimas (kui kellelgi on rohkem huvi Tai vastu siis võin sellest lõputult rääkida eraldi ja meil oli ka reisiblogi (küll mitte päris lõpuni kirjutatud, aga siiski)), seejärel väga suurepärane MVP Summit Seattle’s ning viimaks kui märtsi keskpaigaks püsivamalt (s.t. kolmeks nädalaks, enne järgmist reisi Eestisse) koju sai, siis oli paras kogus tööd juba ees, nii et alles nüüd jõudsin oma blogimise, blogi hostingu kui ka kavas olnud muudatuste kallale.

Esimene muudatus on BlogEngine.NET uuendamine v1.6.1 pealt v2.5 peale. Varasem versioon lasi siiski liiga palju spämmi läbi ja kuna mootor kasutab effektiivselt vahemälu (cache), siis põhjustas kümnete tuhandete postituste kommentaaride omamine serveris paari gigast mälu tarbimist. Igatahes täitsa ebameeldiv kogemus. v2.5 aga tundub mulle väga palju stabiilsemana ja uuendamine ise oli ka väga lihtne – uue installeerimine ja seejärel failide (pildid, postituste manused) kopeerimine uude asukohta ning andmebaasi uuendusskripti jooksutamine. Ei ühtegi probleemi.

Teise sammuna lõin Melborp.NET blogi kaheks – eesti keelne sisu hakkab nüüdsest tekkima aadressile http://www.melborp.ee ja inglise keelne sisu aadressile http://www.melborp.net. Olen juba pikka aega soovinud kirjutada postitusi ka inglise keeles ja nüüd lõpuks võtsin kätte ning tegin ära. Varasemalt olen mitu korda proovinud saanud inglise keelset blogi MVP-de keskkonda, aga siiamaani ei ole see õnnestunud ja enam ei jaksa ka oodata.

Kolmanda sammuna on veidikene ka muutunud disain, aga sellega töö ei ole veel lõppenud. Muudatusi tuleb veel kindlasti, kuigi esimene prioriteet on hakata kirjutama uut sisu, uusi postitusi.

Eneta kommuuniõhtu: Visual Studio 2010 nipid ja trikid

Mon, 13 Dec 2010 09:01:45 +0100

Sellel kolmapäeval on kavas jagada kõikidele huvilistele erinevaid kasulikke nippe ja trikke Visual Studio 2010 –s, mida olen oma viimase aasta jooksul toolbox-i kogunud. Eesmärgiks olen seadnud TOPP 15 nippi ja trikki.

Reklaamimisega olen jäänud mõnevõrra hiljale, kuid vast jõuavad veel enne jõule mõned kuulama tulla.

Üritus on tasuta ja Eneta kommuuniõhtute raames. Toimub IT Kolledžis 15.12.2010 algusega kell 18.00. Üritus on mõeldud enamasti arendajatele ja tasemeks on 300 ehk on väga kasulik varasem kokkupuude Visual Studio-ga.

Rohkem infot ja registreerimine Eneta lehelt:

Eneta kommuuniõhtu: Visual Studio 2010 nipid ja trikid

Loodan, teid kõikki näha sellel üritusel juba sellel kolmapäeval!

Huvitav leid: Convert.ToString(StringBuilder) käitub imelikult null väärtusega

Thu, 14 Oct 2010 23:54:00 +0100

Nagu mõned juba teavad, siis ma elan hetkel Stockholmis, Rootsis ja elu käib siin veidi teistmoodi kui kodumaal. Viimased paar kuud on olnud paras segadus kodu leidmisega siin ja kolitud mitmeid kordi, mille tulemusena on ka blogi maas olnud. Nüüd peaks see segaduste aeg läbi olema. Olen leidnud ühe kena kodu Stockholmi IT linnakus nimega “Kista” ning tegu on pikaajalise korteri üürilepinguga. Tänasest sai ka võrguühendus toimima ja ruuterid konfigureeritud ning blogi (ja muu serveris asuv) on nüüd täie elu juures.

Oma aktiivset blogi postituste perioodi alustaks ühe lühipostitusega (hetkel kellaaeg juba veidi hiline pikemaks postituseks).

Ja nüüd asja juurde. Paljud kasutavad StringBuilder klassi .NET–s, kui on vaja stringi töötlust suuremal määral teha. Ühes kohas, kus ma seda kasutan konverteerin ma StringBuilder’i string’iks kasutades Convert.ToString() meetodit. Muidugi saaks kasutada ka koodilõiku stringBuilderInstance.ToString(), aga see eeldab et StringBuilder alati eksisteeriks, mul aga juhtub ta vahest null olema ning sellisel juhul sooviks et konverteerimise tulemus oleks ka null. Teadupärast null.ToString() annab tulemuseks NullReferenceExceptioni hoopiski. Kuna kood tekstis ei ole kõige kergem viis info edastamsieks, siis läheks näidete juurde.

Oletame, et mul on järgmine koodilõik.

   1: StringBuilder stringBuilder = MingiMeetodMisTagastabNullVõiStringBuilder();

   2: TeeVeelMidagi(Convert.ToString(stringBuilder));

Tähelepanu! Kui te veel ei tea, siis Convert.ToString() on turvaline viis konverteerida mdiagi string’ks. Ehk kui sinna anda null, siis tulemuseks on ka null. Kui sinna anda number, siis sellest tehakse tore string milles on number.

Igatahes, meetod “TeeVeelMidagi()” eeldab sisse saada null, juhul kui stringbuilder instantsi väärtus on null. Kõikkide eelduste kohaselt võiks järgnev koodilõik muutuja “test” väärtuseks saada null.

   1: StringBuilder stringBuilder = null;

   2: string test = Convert.ToString(stringBuilder);

   3: //test == string.Empty, not null!!!

Aga nii see pole, vaid väärtuseks on hoopiski string.Empty (või tühi string). Minu jaoks on see väga imelik käitumine, kuna kirjutades:

   1: Convert.ToString(null);

Saan ma alati väärtuseks null. Miks peaks siis StringBuilder tüüpi muutuja, mille väärtuseks on null, käituma kuidagi erinevalt. Tuleb aga välja, et käitub erinevalt.

Vaadates Reflectoriga järgi, siis näete et puudub Convert.ToString(StringBuilder), küll aga on olemas üldine meetod kõikide objektide jaoks. Antud juhul siis käivitub järgmine koodilõik:

   1: public static string ToString(object value, IFormatProvider provider)

   2: {

   3:     IConvertible convertible = value as IConvertible;

   4:     if (convertible != null)

   5:     {

   6:         return convertible.ToString(provider);

   7:     }

   8:     IFormattable formattable = value as IFormattable;

   9:     if (formattable != null)

  10:     {

  11:         return formattable.ToString(null, provider);

  12:     }

  13:     if (value != null)

  14:     {

  15:         return value.ToString();

  16:     }

  17:     return string.Empty;

  18: }

Kuna antud StringBuilder ei vasta ühelegi tingimusele, siis jõuab jooksutamine viimase reani, kus tagastatakse külma rahuga string.Empty. See on siis käitumine kõikide olevuste puhul, mille jaoks ei ole olemas oma meetodit, vaid läheb objekti alla.

Igatahes, oli see minu jaoks üllatuslik käitumine ja põhjustas ühe bugi lahenduses. Olge ettevaatlik ja ärge eeldage samat käitumist alati. Isegi null võib vahest muutuda tühjaks string’iks (eesti keeles sõne?)

Dünaamiline T-SQL – kuidas jooksutada õigesti?

Mon, 04 Oct 2010 23:55:00 +0100

Antud postituse eesmärk ei ole lahata dünaamilise SQL–i häid (igal asjal on omad plussid) ja halbu külgi (neid on rohkem kui üks) või tutvustada dünaamilist SQL-i, vaid välja tuua näide, kuidas dünaamiliselt ehitatud T-SQL päringut ehitama ja käivitama peaks. Seda ühe lihtsa halva demo näite põhjal. Postitus on ajendatud reaalsest elust, kus ma jätkuvalt kohtan halba dünaamilist T-SQL–i kasutamist.

Igatahes oletame, et on vajadus kasutada dünaamilist T-SQL-i päringuid (näiteks põhjusel, et tegu on otsingu päringuga, kus on mitmeid tingimusi ja filtreid, mis mingitel kindlatel tingimustel kehtima peavad).

Enne veel kui asun asja juurde, peaks selgitama ka seda, mida ma dünaamilise SQL–ina võtan. Antud kontekstis ja minu jaoks dünaamiline SQL on T-SQL päringu stringi kujul kokku panemine ning seejärel selle käivitamine näiteks EXEC(“päring”) kujul.

Kujutame ette, et mul on järgmine andmetabel:

Millel on järgnev sisu:

Järgneb tüüpiline vanakooli dünaamiline SQL. Teeme mingit maagiat, saame sisse Stored Proci sisse parameetrid ning paneme kokku dünaamiliselt SQL –i ning seejärel käivitame EXEC(“”) abil.

   1: declare @name nvarchar(100)

   2: set @name = 'plapla'

   3: declare @Query nvarchar(max)

   4: set @Query = 'select * from Demo where name = ''' + @name + ''''

5:

   6: EXEC (@Query)

Puudused

Antud käivitamise viisil on mitmed tõsised puudused.

Sellele päringule ei looda plaani ning seda plaani siis muidugi ei cachita (ei saada jõudluse eeliseid, mis on Stored Procidel näiteks või parametriseeritud päringutel)
Väärtused ei ole “escaped” kujul, ehk kui teil on SP, millelesse tulevad parameetritena sisse SQL injection (‘select pla from plapla’--) ja teie SP sees ehitate omale usinalt dünaamilist SQL-i ning seejärel käivitate, on oht et teile tehakse ikkagi SQL injection (parimal juhul lihtsalt SP läheb katki sisendi peale).
Kujutage ette, et päringuks on hoopiski “where name like ‘%pla’dart%’ ” – see ei toimiks üldsegi. See ei ole harukordne, näiteks mitmetes keeltes on populaarne kasutada ülakoma nimedes.

Lahendus

Lahenduseks on muundada see dünaamiline SQL ümber dünaamiliselt koostatut parametriseeritud sql päringuks. Kujutage ette, et @name on parameeter Store Proci ning kõik ülejäänud on dünaamilise SQL –i defineerimine selles SP-s. Defineerida on vaja parameetrid, mida päringus kasutatakse. Seejärel päring. Ning nüüd käivitada see päring kasutades “exec sp_executesql @Query, @QueryParameetrid, @param1, @param2, … “.

   1: declare @name nvarchar(100)

   2: set @name = '%pla''dart%'

3:

   4: declare @ParameterDefinition nvarchar(max)

   5: set @ParameterDefinition = '@name nvarchar(100)'

6:

   7: declare @Query nvarchar(max)

   8: set @Query = 'select * from Demo where name like @name'

9:

  10: exec sp_executesql @Query, @ParameterDefinition, @name

Antud päringu tulemuseks üks rida:

Niimoodi käivitamisel on mitmed eelised.

Käivitades luuakse päringule plaan ja see cachitakse.
Ei ole probleemi teha otsingut väärtusega, mis näeb välja väga sql injectioni moodi (nende apostroofide tõttu).

Loodan, et sellest on abi!

ASP.NET turvalisus – paanika patch

Sun, 03 Oct 2010 23:58:00 +0100

Loodetavasti pole see uudiseks kellelgi, et ASP.NET –is avastati tõsine turvaauk (ASP.NET Crypto Oracle Padding Security Vulnearability) kaks nädalat tagasi ning kolmapäev sai turvaprobleemile ka Microsofti poolelt patch välja lastud. Reedel jõudis see patch ka Windows Update –i ning saab nüüd mugavalt paigaldada (WSUS või muud moodi).

Ma ei hakka selgitama milles turvaprobleem seisnes vaid all poolt leiate lingikogu, kust lisainfot saada. Teised inimesed on selgitustöö juba väga hästi ära teinud.

Tooks välja ühe postitiivse nüansi loos, kaks nädalat tagasi reedel sai avalikuks turvaauk ja see oli tõsine ning läks vähem kui kaks nädalat ja sellele oli patch olemas ning windows update kaudu kättesaadav. Ma ei tea hetkel ühtegi patchi, mis Microsoft on välja lasknud niisuguse kiirusega. Nende toote releasimise protsess igasuguse täienduse välja laskmiseks on väga mahukas ja pikk ning pigem juhtub kuu ajaga midagi.

Tundub, et arendus on neil jõudnud nii kaugele, et täiendused/parandused ja nende release ei ole enam nii mahukas tegevus. Seda väidet toetab natukene ka kõik need Power Tool’d Visual Studiole (jm toodete juures), mille release’i tsükkel on kõigest mõned kuud. Vähem kui 10a tagasi ei kujutanud paljud suurfirmad ette, et tarkvara saaks valmida vähem kui 2-3 aastaga.

See kui kiiresti IT’s asjad liiguvad, jääb alati mind imestama panema. Samas see on üks põhjuseid, miks antud valdkonnas ka tegutsen – koguaeg on uut ja uus.

Note: Kui keegi ei ole veel enda veebi serveritesse seda patchi paigutanud või isegi plaaninud paigutada, siis soovitan kiirelt oma käed käima panna. See turvaprobleem mõjutab absoluutselt KÕIKKI .NET –i rakendusi, mis jooksevad IIS –s (.NET enabled web site).

Ja nüüd see lubatud lingikogu:

Ja lõpetuseks üks video antud turvalisuse kuritarvitamisest.

MSP – veel 9 päeva aega

Sat, 02 Oct 2010 17:11:26 +0100

Oled mõelnud, et tahaks teha rohkem ülikoolis olles? Soovid esineda ja jagada oma kogemust, õppida ning kogeda uut tehnoloogia või disaini valdkonnas. Kasutada ja uurida viimast Microsofti tehnoloogiat, ka seda, mis ei ole veel avalikkusele jõudnud?

Praegu on kõigil tehnoloogia ja disaini eriala tudengitel võimalus proovida saada MSP –ks (Microsoft Student Partner) ning aega on jäänud veel 9 päeva, et oma avaldus ära saata.

Kunagi aastal 2003, kui MSP programmi veel polnud, vaid olid Microsoft Tudeng Konsultandid (Microsoft Student Consultant või MSSC), sai just siit alguse minu põnev seiklus ja kokkupuude Microsofti tehnoloogia kui ka maailmaga. Ma olen olnud MuG –i liige kui ka selle loomise juures, ma olen töötanud Microsoftis mitmeid aastaid ja ma olen hetkel MVP Visual Studio ALM –i alal. Kõik see on pakkunud mulle unikaalset kogemust ja teadmist, mis on aidanud mind töökohale, kus hetkel olen ja kindlasti viib mind edasi ka siit. Teod, mis sai tehtud MuG-i, MSSC või MSP aegadel ülikooli ajal on siiamaani mu ühed meeldajäävaimad seigad ja kogemused ülikooli ajast.

Rohkemat infot MSP programmi, avalduse ja muude nõuete/eeliste kohta leiate MSP leheküljelt.

Lisaks olen kogunud erinevad kasulikud lugemismaterjalid MSP teemal:

Kuidas migreerida: nUnit –> MSTest –> nUnit

Mon, 27 Sep 2010 00:03:00 +0100

Arendades võib tekkida vajadus varasemalt kirjutatud MSTestid ümber konverteerida nUniti omadeks või siis nUniti omad MSTestideks. Minul on niisugune vajadus mõnel korral tekkinud ja heameelega dokumenteeriks lähenemise tulevikuks.

Ma kirjeldan ära protsessi MSTesti testide migreerimise nUniti omadeks ning annan lisa viiteid kui peaksite vastupidist migreerimist tegema (mu varasem postitus + ..).

MSTest –> nUnit’iks

Asenda (replace all) järgmised attribuudid oma testi koodifailides:

TestClass ->TestFixture
TestMethod ->Test
TestInitialize –> SetUp
TestCleanup->TearDown
ClassInitialize –> TestFixtureSetUp
ClassCleanup –> TestFixtureTearDown

Lisaks asenda (replace all) nimeruum “Microsoft.VisualStudio.TestTools.UnitTesting” –> nimeruumiga “NUnit.Framework”.

Juhul kui te kasutate MSTest spetsiifilisi meetodeid, siis peate manuaalselt parandama koodi. Abiks on xuniti võrdlustabel erinevate testimisraamistikega.

Lisaks, kui te konverteerite nUniti class library projektist nUniti omaks, siis on vaja teil kohendada projekti faili elementide väärtusi (projekti id-d).

Ning viimase märkusena, pidage meeles, et Visual Studio MSTesti projekt nõuab sama .NET –i versiooni kasutamist millega koos see Visual Studio on välja tulnud (VS2010 seega .NET 4.0, VS2008 .NET 3.5, VS2005 .NET 2.0, … ). Lugege mu postitust, miks see tähtis on.

[Parandus] Ühtegi automaatset vahendit MSTest -> NUnit failide konverteerimiseks ma kahjuks ei tea ja testiraamistiku spetsiifiliste meetodite kasutamise konverteerimiseks automaatika abil oleks parajalt keerukas ülesanne.

Edu!

Testi projekt võiks olla sama .NET –i versiooniga kui päris toode

Sun, 26 Sep 2010 00:40:47 +0100

See pole üks mu nutikamatest leiutistest – kasutada testide projekti, mis kompileerub uuema .NET –i versiooni vastu kui reaalne toote projekt. Ma soovin sellest kirjutada kahel põhjusel:

juhul kui mul tuleb tuhin sama lollust teha, siis ehk meenutab see blogi postitus, miks antud mõte paha on
juhul kui kellelgi teisel on sama mõte või ei pööra tähelepanu antud faktile, siis ehk päästab see väiksest supist teisi

Mul oli olemas testide projekt ehitatud nUniti abil ja testid toimisd ilusti. Aga kuskil sügaval peas paiknes mul mõte, et neid teste võiks ju ka automaatselt iga buildiga jooksutada ja saada kinnitust, et kõik jätkuvalt toimib. TFS2010 puhul kõige lihtsaim viis selleks on MSTeste kasutada. Alati saab konfigureerida Team Build teiste raamistikega ehitatud teste jooksutama, aga tavaliselt on selleks vaja natukene rohkem konfigureerida MSBuild/WF protsessi kui MSTestide puhul.

Igatahes, et kiiremini teste automatiseerida ja et lihtsam oleks teste kirjutada/jooksutada Visual Studio 2010 -s, otsustasin migreerida nUniti testid MSTestide peale ja kui aus olla, siis see oli väga lihtne. Leiate mu varasema postituse selle kohta siit (postitus keskendub veidi muule, aga mainib ära nUnit-> MSTest –i konverteerimise). Kõik testid toimisid ootuspäraselt peale migreerimist.

Tähtis on teada, et Visual Studio MSTestide projekt toimib alati selle .NET –i versiooniga, millega koos ta välja lasti. (VS2010 seega .NET 4.0, VS2008 seega .NET 3.5, VS2005 .NET 2.0 jne). See on nii ehitatud hetkel. Toode mida testin on aga ehitatud .NET 3.5 –ga.

Antud tegevusel oli seega implikatsioon:

Testi projekt kasutas uuemat versiooni .NET –st kui testitav toode oma jooksutamiskeskkonnas.

Implikatsioon, millele oleks pidanud koheselt rohkem tähelepanu pöörama!

Aega läheb mõõda ja teste saab usinalt lisatud. Kõik testid toimivad – on rohelised ja punased vastavalt minu ootustele ja arusaamistele. Tootekoodis on ka hulganisti logimise/träkkimise programmikoodi, mis toodab logisid ja milles olev info aitab analüüsida, kas kõik toimib oodatult ka runtime keskkonnas.

Antud logidesse hakkavad ilmnema vead. Vead mille käsitlemiseks on koodis vastavad täiendused tehtud ja mida ei tohiks kuidagi ilmneda. On olemas ka testid mis tõestavad, et programmikood on korrektselt ehitatud ja antud sisendite/käitumise puhul ei ilmne vigasid.

Pärast mitut tundi pead vastu seina tagumist, kui testid kõik toimivad aga hostingu/IIS keskkonnas tootekoodi jooksutades asi ei toimi, jõuan selleni et võrrelda .NET versioone kahe projekti vahel. Need on erinevad. Migreerin MSTesti tagasi nUnit peale ning proovin testi jooksutada .NET 3.5 –ga. Test ei tooda sama tulemust!

Ma olin unustanud, et MSTesti puhul VS2010 –s pean ma kasutama .NET 4.0 ja sel hetkel kui migreerisin oli testide tulemused ja väljundid samad, kõik tundus toimivat samamoodi. Tuleb aga välja et .NET 4.0 –s on mõned asjad paremaks läinud ja ei visata vigasid, mis eelnevas versioonis pinnale jõudsid.

Konkreetselt on tegu järgneva koodiga, kus kutsutakse välja Stored Procedure, mis tagastab kas XML –i või NULL väärtuse. Programmikood proovib käivitab Stored Proci ExecuteXmlReader() abil ning see haldab NULL väärtuse tagastamist erinevalt .NET 3.5 ja .NET 4.0 vahel.

   1: XElement result = null;

   2: using (var reader = command.ExecuteXmlReader())

   3: {

   4:     if (reader.MoveToContent() != XmlNodeType.None)

   5:     {

   6:         result =  XElement.Load(reader);

   7:     }

   8: }

   9: return result;

.NET 3.5 puhul viskab see järgneva vea “System.Data.SqlTypes.SqlNullValueException : Data is Null. This method or property cannot be called on Null values.”

.NET 4.0 puhul ei visata midagi vaid tagastatakse XmlReader millel on XmlNodeType.None.

Mul on veel anomaaliaid olnud, mis võibolla on seletatavad versiooni erinevusega, ma alles uurin.

Õppetund

Absoluutselt mitte kunagi ei tasu olla naiivne ja mõelda, et asjad toimivad sama moodi kahe .NET –i versiooni vahel. Testi projekt võib olla väärtusetu, kuna kasutab erinevat versiooni reaalsest tootest. Sama reegel kehtib üleüldse arendades - .NET –i versioon peab olema sama kuni Service Packi versiooni täpsusega, alati!

Antud juhul on versioonide osas suurem erinevus ka selles, et CLR on erinev .NET 3.5 ja .NET 4.0 puhul.

Blogimootor uuendatud BlogEngine 1.6.1 peale!

Tue, 03 Aug 2010 01:43:43 +0100

Täna sai siis lõpuks kõrini versioonist BlogEngine.NET 1.5.0.7 ning viimane tunnikene olen uuendanud enda kui ka neiu blogimootori BlogEngine.NET 1.5.0.7 pealt 1.6.1 peale. Mitte, et vanemal versioonil oleks näiliselt tõsiseid puudusid olnud. Pigem väsisin spämmist. Ma olin ise teinud 1.5.0.7 –le pisitäienduse ning lisanud Asirra Captcha külge. Minu implementatsioonil tundub aga olevat mõned augud, sest vaikselt tilkus umbes 16 spämmi kommentaari. Neiu blogil läks veidi hullemalt, tal tekkis neid tülikaid kommentaare rohkem, seega oli aeg ära vahetada.

Uuel versioonil on recaptcha sisse ehitatud ning hetkel on see meie mõlema blogil toimimas. Uuel versioonil on veel täiendusi nagu tsentraliseeritud kommentaaride haldus (spämmi mõnus kustutada), mõni turvapaik, twitter widget pakub rohkemat, loggimine, paranenud vigade haldus jne.

Asirra Captcha osas ei oska hetkel seisukohta võtta – mulle see kasside ja koerte vahel valimine täitsa meeldib, aga arvan et pean hetke laienduse ümber ehitama ning kindlamaks tegema. Pole veel otsustanud, kas ja millal aja võtan selle jaoks.

Kasuliku juhendi BlogEngine.NET v1.5 pealt 1.6 peale uuendamise kohta David Wynne blogist. Ainukene lisa, mis ma siia teeks on see, et kui kasutate SQL –i andmebaasi andmete hoidmiseks, siis peale juhendi järgimist tuleb nii connectionstring (loogiline) kui ka vaikimisi providerite (defaultprovider) “DbXProvider” –ite vastu vahetada (blogprovider, membershipprovider, roleprovider). Vaikimisi toimib mootor puhtalt XML-i peal.

Samamoodi tuleb teil jooksutada muidugi andmebaasi script v1.5 –> v1.6 uuendamiseks.

Lisainfot:

BlogEngine .NET 1.6 Release notes
BlogEngine.NET 1.6.1 update notes
Kuidas sisse lükata recaptcha 1.6.1 versioonis
Juhend uuendamaks BlogEngine.NET v1.5 -> v1.6
PS! Selle postituse all on ka juhend kuidas v1.6 –> v1.6.1 ilma et teha täis uuendust.

VS2010: Laienduste haldur pakub ka uuendusi!

Sat, 31 Jul 2010 00:56:34 +0100

Mulle meeldib VS2010 –e laienduste haldur (Extension Manager) kahel põhjusel:

Sellega saab otsida laiendusi ja lisasid Visual Studiole
Sellega saab teada, kui installeritud laiendustele on uuendusi

Mõnus vahend, mis väldib vajaduse käsitsi minna Visual Studio Gallery lehele.

Proovige ise järgi, kui veel ei ole!

Mõni teinekord kirjutan, mis lisasid veel kasutan Visual Studio 2010 sees. Kahte näete uuenduste näol juba ees pool oleval pildil.

Tip: Entity Framework, andmebaasi protseduurid ja väljund parameetri väärtus

Sat, 31 Jul 2010 00:33:33 +0100

Antud nipp on kindlasti kogenumatele EF-i (Entity Framework) ja SQL serveri andmebaasi protseduure (stored procedure ehk SP) kasutavatele arendajatele teada. Mina näpin EF-i niimoodi vahelduva eduga ja vahest satub mõne orka otsa lausa mitu korda. See on üks nendest oradest. See on ka selles mõttes ora, et normaalne ja loogiline (loe: oodatud) käitumine oleks teistsugune.

Oletame, et mul on üks andmebaasi protseduur (SP), millel on üks sisend ja kaks väljund parameetrit (kusjuures väljundparameetrite arv antud juhul ei oma mingit tähtsust).

   1: CREATE PROCEDURE [dbo].[Test_Sp]

   2:     @someval INT,

   3:     @ValueOut INT OUTPUT,

   4:     @ValueOut2 VARCHAR(50) OUTPUT

   5: AS

   6: BEGIN

   7:     SET NOCOUNT ON;

8:

   9:     SELECT  @ValueOut = COUNT(*), @ValueOut2 = 'misiganes'

  10:     FROM [MingiTabel]

11:

  12:     SELECT * FROM [MingiTabel]

  13: END

Seejärel loon omale EF-i mudeli ning lisan SP antud mudelisse, et oleks strongly typed lähenemine (kood) protseduuri väljakutsumiseks.

Kõik on ilus ja toimib suurepäraselt. Kirjutan ka koodi, mis antud protseduuri välja kutsub ja antud juhul lihtsalt kirjutab konsoolile.

Nüüd antud koodi oodatav väljund lugedes oleks, et “[MingiTabel] ridade arv“, “misiganes”. Päriselt on aga väljundiks:

Nüüd on aeg veidi pead kratsida ja mõelda, mida see EF õige mõtleb. Kui te SQL Profileriga vaataksite, siis te näete et OUTPUT väärtused ilusti tagastatakse. Objekti parameetritesse need aga ei jõua.

Asi nimelt selles, et antud protseduur tagastab kaks asja – select lause tulemuse (loetelu mingitest objektidest) ja need kaks väljund parameetrit. EF eeldab, et oma täie mõistuse juures olles kõigepealt soovite loetelu mälusse saada ja alles seejärel on teil huvi nende väljud parameetrite vastu. ObjectResult<T> tundub olevat käitumise poolest sarnane olevus IQueryable<T> –ga, et andmed laetakse siis kui antud tulemusega soovitakse midagi peale hakata (n-ö lazy loading ehk laisk laadimine) ja alles seejärel on muutuvad väljundparameetrid kättesaadavaks.

Tip! Seega väljundparameetrite kättesaamiseks peate materialiseerima (kui nii võib kirjutada) oma loetelu ja siis on väljund parameetrite väärtused olemas. Toimiv kood näeb välja järgmine:

Ning tulemus.

Edu!

Jama: Meili saatmine blogi kaudu ei toiminud peale Rootsi kolimist!

Thu, 29 Jul 2010 00:48:00 +0100

Täna avastasin, et meilide saatmine blogi kaudu oli katki. Mul oli see konfigureeritud kasutama ISP SMTP serverit ja muidugi pärast kolimist rootsi, et olnud enam ISP sama.

Nüüd muutsin meili seaded nii, et kolimine enam mind ei mõjutaks.

Vabandan kõigi ees, et meile saatsid! Ei saanud neid ühtegi kätte. Palun saatke uuesti või suhelge kommentaari näol siin või postitusena ENETA foorumis (abistajaid rohkem).

Antud nüansi tähelepanemine võttis mõnevõrra aega, nagu näha

Tip: Kuidas saada klassikogumi projektist VS Test Projekt

Thu, 29 Jul 2010 00:42:00 +0100

Projektides võib ikka juhtuda, et te kasutate oma lahenduse ühik testimisel (unit test) mõnda teist raamistikku, kui MSTest. Mina näiteks kasutan vahest nUnitit või xUnitit. Mulle meeldib xUniti erinev testi kirjutamise stiil ja mulle meeldib nende mõlema puhul see, et raamistiku kasutamiseks saab kasutada tavalist klassikogumi projekti. Ka on nende testide jooksutamine kohati kiirem.

Nüüd vahest võib ka juhtuda nii, et teie mitte MSTesti raamistikul testid on vaja üle viia MSTesti raamistiku peale ning kasutada Test Projekti. Mul tekkis konkreetne vajadus sellest, et MSTesti projekti on lihtsam kasutada üle terve meeskonna, juhul kui kõik kasutavad ainult Visual Studiot. Ei ole vaja eraldi vahendit jooksutamiseks. Ka on integratsioon Team Buildiga vaikimisi toimiv, teiste raamistike puhul on vaja Team Buildi muuta vastavalt ja eraldi vaeva näha (mitte väga suur keerukus, aga siiski aeg). MSTestil on veel eeliseid ja erinevusi, aga see postitus ei ole õige koht selle jaoks.

Igatahes, on vajadus muuta nUniti projekt (class library) ümber MSTest-i raamistikul jooksvaks projektiks (Test Project).

Võrdlemisi lihtne konverteerimine:

Asenda ühed attribuudid teistega (abik xUniti võrdlus erinevate unit testimis raamistikega)
Eemalda projektist nUniti viide assembly’le
Lisa projektile viide MSTest unit testimis assembly’le (Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll)
Muuda koodi, kus MSTestis ei ole vastavat Assert väljendit nUnitile (nagu Assert.Throws = [ExpectedException] etc.)
Asendada using nUnit… väljendid using Microsoft.VisualStudio…. väljenditega
(arvan et pole kohustuslik) lisada .vsmdi ja .testsettings failid solutionisse.

Põhimõtteliselt muud nagu ei olegi, kõik väga loogiline. Seejärel kompileerite ja proovite Test View abil näha oma suurepäraseid ühik teste, mis nüüd võiks toimida kõik MSTest abil. Ja mida te näete? MITTE MIDAGI!

On veel üks tore samm, mis on vaja teha, et Visual Studio saaks aru, et tegu on testi projektiga ning vahend oskaks otsida teste ja neid kasutada.

Teil on vaja lisada oma klassikogumi projekti faili uued projekti tüübi identifikaatorid (ProjectTypeGuid –d).

Kõige lihtsam viis neid leida on luua tühi TestProjekt ja editeerida projekti faili ning XML-st üles leida element nimega “ProjectTypeGuids”.

Nendeks on järgmised GUID-d:

   1: <ProjectTypeGuids>

   2: {3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}

   3: </ProjectTypeGuids>

Pärast nende lisamist projekti faili on elu ilus ning testid peaksid jooksma!

NB! Lisaks siia veel ühe tähelepaneku Test Projekti puhul - see peab kasutama seda versiooni .NET-st, millega koos Visual Studio välja tuli ja mis on vaikimisi raamistik (VS2008 puhul .NET 3.5, VS2010 puhul .NET 4.0). Iseenesest ei ole see takistus või probleem, kuna testi projekti ju keegi kuskile ei paigalda ja arendajatel on tavaliselt ikkagi samad versioonid Visual Studiost (või siis on paksu pahandust mitme erinevat versiooni VS solution ja project failidega).

Edu konverteerimisega, kui peaks vajadus olema!