Darbs pie mākoņa rit pilnā sparā.
Viens no klupšanas akmeņiem uzsākot darbu ar Windows Azure.
Kā jau ieraksts – kurš gan developeris instalē kaut kādus SQL Express redakcijas uz lokālā datora. Normāls kekss iet ar pilno SQL instalāciju un vēl groziņā ieliek Business Intelligence Development Studio, Analytic Services un SSIS :).
Protams, ir gadījies saskarties ar cilvēkiem, kuri apgalvo, ka viņu kods ir pilnīgi bez kļūdām un Debugger ir bezjēdzīgākā Visual Studio feature, bet par cik nepiederu pie šī elitārā grupējuma un atkļūdošana manam kodam ir nepieciešama, tad tā nu lūk viens no skaņošanas un atkļūdošanas režīmiem Windows Azure platformā, ja izmanto Windows Azure Storage servisus (tabulas, rindas vai BLOB vietas), ir local Storage Emulator, kas dod sajūtu, ka programma griežas pie reāla Azure Storage servisa un programmu ir iespējams darbināt gandrīz vai reālos ražošanas vides apstākļos.
Tātad ir forši, ka lokāli var izkustināt Windows Azure aplikāciju un aplūkot kā tā darbojas. Ja sistēma izmanto Azure Storage pakalpojumus, tad lokālā simulācijas būs nepieciešama.
To ir iespējams ļoti vienkārši iedarbināt:
- sistēmai īpašībās atzīmējam, ka mums ir nepieciešama Azure Storage pakalpojumi un mēs izmantosim lokālo izstrādes vidi
- vai nu no Visual Studio laižam sistēmu ar F5 vai arī iepriekš varam jau palaist gan Azure Compute (emulators, kas nodrošina virtuālās mašīnas simulāciju, kas līdzinās Windows Azure Role virtuālajai mašīnai), gan Azure Storage (emulators, kas simulē Storage pakalpojumus) simulatorus.
Parasti Azure Compute simulators palaižās kaut kā baigi ātri un bez kļūdām, bet ar storage simulatoru gan ir citreiz ziepes.
Parasti defaultajā developer workstation setupā pie pirmās Windows Azure Storage Emulator palaišanas (tas bija aktuāli, kad savas virtuālās izstrādes vides etalona image mēģināju stabilizēt) ieraugām pilnīgu NEKO, kas nozīmē, ka Storage simulators kaut kā īsti laikam ka negribas startēties.
Parokamies nedaudz dziļāk Windows Azure SDK folderos un atrodam, ka šim storage simulatoram ir atsevišķa .exe programma, kuru var dabināt stand-alone (es ceru, ka Microsoft šeit ir parūpējies par to, ka .exe ir tikai un vienīgi fasāde un biznesa loģika ir centralizēta kādā vienotā citā komponentē – tā arī izrādījās patiesība vēlāk pēc koda dekompilācijas).
Stand-alone interfeiss atrodas: “C:\Program Files\Windows Azure SDK\v1.4\bin\devstore\DSService.exe”.
Palaižot šo programmu varam vismaz ieraudzīt kļūdas paziņojumu, kas notiek pie Storage simulatora palaišanas no kopējās tray ikonas programmas – interesanti, ka tray ikonas programmā exception tiek norīts – kam negadās :)
No sākuma gan izstās viss baigi OK (servisi ir “Starting” režīmā):
Neilgi pēc kāda brīža (precīzi pēc SQL server connection timout) ieraugām īsto paziņojumu:
Un pēc tam UI daudzsološs paziņojums par to, ka servisi ir “Running” režīmā:
Lai nu kā, nolēmu ielūkoties, kas notiek pašā “DSService.exe” programmā (izmantoju Just Decompile no Telerik) un secināju, ka šis lasa no kaut kāda konfigurācijas faila nepieciešamo servisa konfigurāciju. Fails atrodas “C:\Users\{User name}\AppData\Local\DevelopmentStorage” folderī. Un kā nu ne, atradās arī SQL instance, kuru Storage emulators pēc noklusējuma uzskata kā defaulto:
<SQLInstance>.\SQLExpress</SQLInstance>
Samainot SQL servera un instances nosaukumu uz kaut ko sakarīgāku (piemēram, “.\”) ieraugām nākamo kļūdas paziņojumu:
Dotajā momentā šis laikam nozīmē, ka savienojums ir izveidots sekmīgi, bet trūkst datu bāzes.
Palasot nedaudz internetā un pārlūkojot to pašu direktoriju, kur atrodas mūsu serviss, atradu, ka pastāv tāda programma kā “DSInit.exe”, kas paredzēta SQL servera inicializēšanai tieši darbam lokālajā simulācijas režīmā.
Komandrindiņa “dsinit.exe /sqlinstance:.” dod vēlamos rezultātus:
No tray ikonas programmas arī pārliecināmies, kas servisi strādā sekmīgi:
Tādi lūk pīrādziņi :)
Cerams, ka noderēs!
The post Inicializēt vietējo Storage Emulator appeared first on Valdis Iljuconoks | Tech Fellow Consulting.