Cloud as a Story - Vunvulea Radu

Last day, one of my colleges had to move some configuration items from application configuration file to cscfg files (Windows Azure Service Configuration Schema). He tried for some hours to move the configuration to cscfg files but without success. Even if the configuration was done 1 to 1 to the msdn example and the project was built and deployed with success, the configuration could not be accessed. In the next part of the post I will describes the steps that were done by him:       1. Identify the configuration that need to be moved in the configuration file: <add key="BingKey" value="XXXXXXXXXXXXXXXXX" />       2. Create the key definition in the csdef (Windows Azure Service Definition Schema) file: <ServiceDefinition .. <WebRole ... <ConfigurationSettings> <Setting name="BingKey" /> </ConfigurationSettings> </WebRole> <ServiceDefinition>  ...

I think that all of you use configuration files. When we are working with a complex project, where many developers need to configure their environment in a way to have a custom configuration, there are cases when they install some application in different locations for example, or they have the SQL server with a different name. What we can do with these cases? In a perfect world we would not have this problem, but for example a part of the team want to use the SQL Azure and another part of the team want to use their own SQL server instance. When the configuration is in the web.config or in the app.config, Microsoft offer to us a very nice solution. We can have different configuration for each developer (on their local machine). Each time we will rebuild the solution, the configuration file will be regenerated. This feature is supported from Visual Studio 2008 2010, but is not well known by all developers. In the next part of the post we will see how we can configure our project to ...

In acest post o sa vedem cum se pot adauga configurari custom in cadrul proiectului Windows Azure, iar apoi sa le putem accesa din cod. O parte din configurariile unei aplicatii se tin de obicei in fisierul de configurare (app.config sau web.config - de la caz la caz). Insa, cand lucram la un proiect care o sa ajunga in Windows Azure putem sa facem aceste configuratii si in alta locatie. De exemplu putem ca aceste configuratii sa le tinem in proiectul de deploy pentru cloud. In felul acesta, putem sa avem mai multe configuratii pentru mai multe environment si/sau chiar sa avem configuratii diferite pentru local si cloud fara sa ne definim un mecanism special pentru acest caz. Primul pas care trebuie facut este sa deschim fisierul ServiceDefinition.csdef din proiectul de deploy pentru Windows Azure. In cadrul acestuia sub nodul WebRole sau WorkerRole (depinde unde aveti nevoie) este nevoie sa adaugam un nod denumit ConfigurationSettings. In acesta este nevoie sa ne definim lista de conf...

Daca vrem sa pornim mai mult de un serviciu in acelasi proces avem nevoie sa apelam urmatorul cod: services = new ServiceBase[] { new DeleteService(), new CopyService(), new LoadService(), }; ServiceBase.Run(services ); Dupa ce o sa executam acest cod o sa avem surpiza sa observam ca doar primul serviciu din lista a ponit. In prima faza ne gandim ca avem acelasi nume, asa ca verificam la cele trei servicii numele. Totul pare in ordine. Urmatorul pas este sa setam serviciul pe "Share" type. Pentru acest lucru trebuie facut: sc config "NumeServiciu" type=share Dar din pacate problema se manifesta in continuare. Doar primul serviciu din lista de servicii porneste. Am renuntat la acesta idee si am facut cate in install pentru fiecar...