Sellest, kuidas panna TFS workspace tuvastama failisüsteemis toimunud muudatusi..

TFS ei ole versioneerimisprogramm, vaid Visual Studio laiendus, mis tegeleb versioneerimisega (ja mille külge on ehitatud ohtralt muid tulesid-vilesid). Seetõttu on minu kui CVS/SVN pealt Microsofti maailma sattunule alati pinnuks silmas, et ma ei saa faile muuta-lisada failisüsteemi tasemel või mõne teise programmi abil. Failid on read-only ja isegi kui sa neid muudad, siis Visual studio ei saa aru, et need on muutunud. Vähemalt mitte enne kui sa oled kõiki neid muutnud KA Visual Studios.

Osutus, et olukord pole lootusetu ja teised hädalised on TFSile kargud teinud: Team Foundation Power Tools, mis sisaldab toredat utiliiti nimega tfpt, mis muuhulgas võrdleb workspace kaustu versioonihalduse infoga ja lisab lisandunud-muutunud-kustutatud failid pending muudatusena.

C:\WM\TFS\SomePath\src>tfpt online /diff /recursive /adds SomeProject

Getting your pending changes from the server...
Checking the status of C:\WM\TFS\SomePath\src\SomeProject... Done
Walking C:\WM\TFS\SomePath\src\SomeProject... Found 20

Mille peale leitakse muutunud failid ja kuvatakse VS sarnases aknas:

Valitud muudatuste kohta jääb konsooliaknasse ka logi:

Edits:

SomeProject:
www_otsing.asp
www_paring.asp
www_teade.asp

Adds:

SomeProject\DBKontroll:
SomeSql.sql

Loomulikult saab ka antud aknast loobuda ja kõik välja checkida kasutades võtit /noprompt.

Mina pean seda funktsionaalsust regulaarselt googeldama, ehk nüüd on kergem leida..

PS: Power tools võimaldab ka explorer integration vahendeid, mis võiks sarnased tegevusd veel mugavamaks teha, kuid neid ma ei ole julgenud proovida. Nagunii hakkab soovimatutel hetkedel päringutega servereid pommitama.

Sellest designer-faili sünkroniseerimisveast..

Juhtus sedamoodi, et kirjutades aktiivselt ühe ascx märgendeid, avastasin koodiaknasse pöördudes, et intellisense ei paku mulle äsja markup'is kirjeldatud elemente. Kiire pilk ascx.designer.cs klassi kinnitas - pooled elemendid on sealt puudu. Salvestamisel ei mingit viga.

Selgus, et selle asemel et runtime'is viga püüda kätte saada, on olemas lihtsam viis: kustuta designer fail ära ja vali ascx pealt "Convert to web application". Selle peale ütleb ta ilusa veateate mis teda sünkroniseerimast takistab.

.. ja tagasi markup'i.

Sellest kuidas saada VS Setup projekti alla puuduvad installer-pakke..

Tavalisi asju nagu erinevaid .NET Framework versioone, Reportviewer, Crystal jms. Abiks on Bootstrapper Manifest Generator mis vimaldab muuhulgas valida võimalikke pakke ja neid veebist masinasse õigesse kausta alla laadida.

Dowload ja muu jutt on leitav: http://code.msdn.microsoft.com/bmg

Sellest, kuidas Winforms rakenduses VS genereeritud koodi partial failidesse saada..

Microsoft .Net 2.0 üs meeldivamaid featuure (nullable tüpide kõrval loomulikult) on partial võtmesõna ja sellega seonduv. See võimaldab kenasti geneereeritud koodi ja käsitsikirjutatud koodi lahus hoida, millega kaasaegne VS (näiteks 2008) ka kenasti hakkama saab. Paraku vanad rakendused, mis on loodud .Net Framework 1.1 ajal hoiavad kõike seda ühes failis. Proovige teinekord ülekäteläinud 6000 reaga failist loogika muudatust otsida. Diff ei ole just ideaalne lahendus ;)

ASP.NET rakenduste korral on projekti failidele designer-partial klassi loomine lihtne. VS ise pakub selleks projekti hüpikmenüüs käsku "Convert to Web Application" vms. Winforms korral see võimalus aga puudub. Google oli armuline ja andis selleks puhuks mulle lingi http://coolsoft.altervista.org/DeCodEx

Ehk väike programm, mis minu põgusa testimise tulemusena teeb monoliitsed vormifailid üle valitud VS projekti kenasti partial tüüpide peale.

Sellest et WinFormsi designer seob arendajate käsi-jalgu..

Seoses hiljutise vajadusega Winforms rakenduse UI'd programmeerida, sai pisut komistatud Winformsi piirangute otsa..

VIsual Inheritance on puudustega

Visual inheritance on siis graafiliste elementide pärimine - näiteks kõikide vormide baasvormile logo panemine võiks käia VI kasutades vormide pärimisega, kus esimene vorm sisaldaks ainult logo ja kõik pärivad vormid saaksid õige logo kohe õigesse kohta. Baasvormi muudatused (näiteks logo vahetamine, mõõtmed jms kajastuks automaatselt kõigil vormidel. Ilus näide koodi korduvkasutatavusest ja UI standardiseerimisest. Paraku, nagu selgus, on enamasti kaval VI'd vältida

Visual inheritance töötas kenasti kuni Visual Studio.NET versioonini. Pärast seda ehitati asju niipalju ümber, et kadus tugi konteiner-komponentidele. VI kannab need pärija-vormile küll kenasti üle, aga nende property'd ei saa enam muuta. Control-id, mis seetõttu muutuvad üle VI tarbides kasutuks on näiteks:

• Panel, FlowLayutPanel, TableLayoutPanel - mis kasu on paneelist designeris, kui sa ei saa sinna midagi sisse panna ?
• DataGridView - ei mingid Designeris propery'te sättimist.
• ... (neid on veel).

Käesolevas projektis ma leidsin, et eeltoodu põhjustel polegi mul VI'd vaja. Logo-control'i lohistamine on lollikindlam kui VI kõigi oma lollide piirangutega. Selle asemel võiks ju kasutada tavalist pärimist .. Selgus, et seegi ei ole nii lihtne:

 

Winforms vormid ei saa pärida generic-klassist

Kusjuures pärida tegelikult saab. Kood kompileerub kenasti ja isegi töötab kenasti. Paraku aga kaob sellega ära Designer-vaade ja asendub koleda ja segase veateatega. Kuna töövahenditega kaklemine ei ole lõbus siis seega on soovitatav Winforms vormide generic baasklasside kasutamist vältida või kasutada triviaalset häkki: luua proxy-klass vormi ja generic-klassi vahele. Sellest räägitakse ka näiteks siin.

Oluline näib olevat ka see, et baasklassil oleks parameetriteta konstruktor, kuna VS2008 Designer loob designeri avamisel baasklassist instantsi. Praktikas tähendab see seda, et sa ei saa pärida abstract markeriga baasklassist. Sama funktsionaalsus on küll saavutatav vastavad komponendid virtualina deklareerimisega, aga loomulikult ei ole see nii ilus lahendus. Samuti tuleb praktikas hoolitseda et baasklassi käivitamisel exceptionit ei visataks. Vajadusel on kaval design-ajal koodi üldse mitte jooksutada wrappides vea andva koodi näiteks nii:

   1:  if (LicenseManager.UsageMode != LicenseUsageMode.Designtime)

   2:  {

   3:      //this is called only in NOT design-mode:    

   4:  }

Tasub veel märkimist, et kuigi eelpool-toodud koodirea asemel saaks kasutada ka controli DesignMode property väärtust, siis see ei ole väga hea mõte, sest see ei tööta konstruktoris ja aktiivse designer-akna user-controlite koodis..

Design-time'i on võimalik debugida

Kuidas teada, mis koodi Visual Studio designTime'is käivitab ?
Lihtne.
Pane breakpoint sind huvitavasse kohta ja määra, et debugimisel käivitataks programmina VS devenv.exe, mis avab uue Visual Studio akna, kus saad õige solutioni laadida, ja erinevaid design-time aknaid avades breakpointidesse joosta.

Testid tehtud : VS2008 Professional Edition + Windows Server 2003

Sellest kuidas Enterprise Library konfigureerijat kasutada VS2008-siseselt..

Ennemuistsel ajal (loe: siis kui kasutamisel oli Visual Studio 2005) oli Enterprise Library seadete muutmine mugavalt otse IDE's. Visual Studio 2008 ei taha neid paraku automaatselt tunda, mistõttu peab huviline kas käsitsi XML'is hullama (võimalusega pisut rohkem näpukaid teha) või järgida Scott Densmore juhiseid siin.

Lühidalt lugu järgmine:
Eeldused:

1. installitud VS2008
2. installitud Enterprise Library 3.1 (May 2007)

Tegevused:

1. pane faili sisu registrisse. NB! kui su install on mittedefault-kaustas, siis heida vastav pilk ka registry faili sisse ja tee vajalikud parandused.
2. VS2008 command-prompt'is : 
   > devenv /setup

Jei, mul toimis probleemideta.