Botched Deployment

Question

I am working on the final parts of the StockTrader 5 sample and I accidently upgraded some DB schemas on SQL Azure without the correct upgraded StockTrader bits, so the site was down for a little while today.  I fixed the issue.  Anyway, I am almost ready to publish the Config Service bits with a live demo version of ConfigWeb 5.0 that goes along with the sample.  The idea is that I will publish ConfigWeb 5.0 to Azure, and let everyone log in as a demo 'admin', so you can check it out, but people can't change the working configuration like a real admin could (for exampe, changing bindings, security settings, etc.).

At any rate, the new Configuration Service 5.0 is a major, major update. I have been working hard, and if you want to help test it, consider the deployment to Azure in the next couple of days a chance to test it out ni the cloud and report bugs.  I plan to finish the sample installer this week and post the full sample source code by Monday (1 week); but the Azure ConfigWeb test-out should be live in next couple of days, I hope.  Its meant to show off some of the things you can do on Azure, and hopefully prove useful to folks as shared libraries in your own apps if you like it.  Some of the changes:

-Testing on Azure and cross service domains between Azure and my private lab uncovered several areas I needed to address.  I did. From https/transport security to message security to transport-with-message-credentials, hybrid deployments, whether username or X.509 certificate client credentials, I have tried most, across wshttp2007 binding and net.tcp.  So StockTrader will have all these bindings and service behaviors, so you can set the security mode when you install locally (or on Azure) when the source is published.  I will ship some test-certificates, and instructions on how to install if you want; if not, the sample (web app, BSL and OPS) will work without as well on the initial install.  All the code runs locally, or on Azure (Azure projects just reference the same shared libraries/use same web pages).  Config Service does the right thing wrt to mapping to Azure internal and input endpoints for services.

-I spent a lot of time on the UI, major cleanup of HTML/ASP.NET both for stocktrader and configweb; I have been testing on IE, Firefox, Chrome and Safari.  The new UI's render well in all of them, although I have been running all on Windows mostly..Also with Win Phone 7, and my friend showed me everything looked good on IPhone as well (Apple mobile safari).  At any rate, this might sound minor, but, since both StockTrader and ConfigWeb are in the cloud, pretty important.

-Service Map (SOA map) now also can (optionally) pull up databases your services/apps might be using, just to complete the picture.

-Added perf metrics (base level) to Service Map--so you get a live view across instances and summary at cluster level of CPU%, ASP.NET req/sec, WCF req/sec (global counters, but you could modify code to show anything you want).  Some other goodness you can explore here.

-Ability to turn on basic logging/tracing to database, if you want, plus views in ConfigWeb of the log. You can have each service write to its own log DB, or all services share a common log DB.

-Too many other enhancements to mention here.  Again, as sample code, and can be used/extended if you think useful. Look for the trial deployment on Azure this week, then full sample source hopefully by Monday...we'll see how it goes.

-Greg 

---

Greg Leake, Microsoft

Answer 1

Any word on the source?

Also, I'm not sure how big a departure the new version of the Configuration Services is from v4 but there was a bug in v4.0 wherein during initialization the configuration service attempted to load the application configuration file using the following code:

 

   //Get this exe name.
   Assembly thisExe = Assembly.GetEntryAssembly();
   //Get the full path to config.
   string path = thisExe.Location;

   returnConfig = ConfigurationManager.OpenExeConfiguration(path);

The above is from the getConfig method of ConfigService.ServiceConfigurationHelper.ServiceConfigHelper

The problem with this is that Assembly.GetEntryAssembly() can be null so I was getting null reference exceptions.

An alternate approach could be: 

 

      var path = AppDomain.CurrentDomain.SetupInformation.ConfigurationFile;
      var fileMap = new ExeConfigurationFileMap {ExeConfigFilename = path};
      returnConfig = ConfigurationManager.OpenMappedExeConfiguration(fileMap, ConfigurationUserLevel.None);

 

 

---

Jimit Ndiaye

Answer 2

Thanks, I remember your earlier post and I will make sure to get your fix in.  I am getting very close, I won't make predications anymore, but am at stage where I am done testing; doing setup that has to work on prem and on Azure (creating databases, etc).  I am going to optionally auto-create sql azure databases from setup (plus provide scripts that can be run outside of setup), but not auto-deploy Azure projects --users can just click 'publish' and deploy to their accounts if they are using Azure.  On-premise, will autocreate the web sites, etc.  I will be working the weekend (as every weekend these days) on setup, also the new docs for implementing.

Its not really that its a departure from 4.0 (your fix still needs to go in, for example); just works a lot better I hope, and works on Azure, and has more features.  As far as implementing it, pretty much the same so existing startup code just needs a tweak, BUT config databases are different (new columns, same tables).  ConfigService contract also differs in key areas to deal with new data, etc.  So, existing 2/4 version repositories would need to be recreated and existing data added back in from 4.0 version.  If I do a 'conversion' tool, it would be after publishing code becuase doing one first would just delay publication of code.  Another thing I have invested time in is VS templates to make implementing very easy.  This version will require .NET 4.0 and VS 2010.  Should be able to deploy on Win server 2003, Vista, Win Server 2008, server 2008 R2, Windows 7, 32/64 bit for all of these.  So lots of testing as well here.

Also had some decisions to take regarding default for StockTrader on-premise and on Azure.  For on-premise, will just use http and net.tcp endpoints with no imposed WCF security.  This makes easier to get going as a developer, without dealing with test x.509 certificates.  For the azure project, am shipping test x.509 certs that web and worker role azure projects will be pre-loaded with, but users will need to upload these to their azure hosted services before publishing the projects to azure.  I think its best to default to high-security on Azure/public internet versions, just as best practice even though just a sample app.  That also means setup has to prompt user to set passwords for config service and for the stocktrader services themselves (which can be configured to use x.509 cert client credentials or username credentials).  So, the devil is in such details plus more given the breadth of the sample and all the different hosts and configurations it demonstrates.  And getting everything as turnkey as can be from a customer install perspective, considering its an end-to-end sample with 3 tiers, configweb, etc.

Thanks again for the bug report...Its very close now.

-Greg

 

 

---

Greg Leake, Microsoft

Answer 3

OK, I looked at and what I have change to is:

ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);

This seems fine for local .exes and for Azure Worker Roles in my tests.  Let me know.  This does not apply to Azure Web Roles or IIS-hosted apps, that call is different for web.config.

-Greg

---

Greg Leake, Microsoft

Answer 4

Hi Greg,

I'm not sure if the above will work for dynamically created appdomains. For instance, in my scenario the main .exe was not the main appdomain from which the config service was being loaded. Your safest bet is to locate the configuration file from the AppDomain's setup information and load it from there. That should work for all scenarios. Or at least use that as the default, falling back to the above call only if AppDomain.CurrentDomain.SetupInformation.ConfigurationFile is null (I'm not sure if it can be but just in case).

Jimit

---

Jimit Ndiaye

Answer 5

Ah, now I understand.  I will use your logic--thanks very much for letting me know...

 

---

Greg Leake, Microsoft

Answer 6

Hi Greg

congratulations on the new release (planned)

Still digging on 3.0/4.0 :) and you alredy have 5.0, which I gess is a big leap. We've been moving some of our apps to cloud infrastructure, i mean IaaS (dedicated server), not exactly Azure like PaaS (although there are differing views as to whether azure is Iaas or PaaS :) ).

It look like a very significant upgrade from 4 to 5, which you say will work in a hybrid scenarios, and opens flood-gates to the cloud. Will await the release and hope to test it out, firstly the basic and then the cloud.

Will email you details of my current challenge if that's ok.

Once again, great going greg.

Cheers

- satish

Answer 7

Hi Satish,

Good to hear from you again. Yes, 5.0 is a big leap, although as you note I have not yet gotten the code up on MSDN, its still forthcoming. Please email me with your current challenge ([e-mail]), I am eager to hear about it. While I tie up the loose ends on StockTrader and ConfigService 5.0 to get the code out (I am at TechEd in Atlanta currently, and carving out as much time as possible to finish this up so its as turnkey and tested as can be) you can check out the StockTrader 5.0 deployment and the Config Service 5.0 on Azure, since everything is already deployed there.  I just added the hybrid cloud deployment for StockTrader 5.0 on Friday (you can see this in the new Service Map view and drill down into my private on-premise lab via ConfigWeb).  Hit https://azurestocktrader.cloudapp.net/ and then hit the ConfigWeb menu link since I also have ConfigWeb deployed in the cloud.  There is a demoadmin/'demo' login for ConfigWeb so you can see, but cannot change, the current config and deployment.

-Greg

 

---

Greg Leake, Microsoft