HI,
I was one of the voters for the auto-scaling application block (wasabi) and was evaluating for one of my projects requirement. I have a few queries whose response if received would be very helpful for the inclusion of this application block in our projects.

1. After the installation of the package using NuGet, when I tried to edit the application config of the host (for the wasabi) using the Enterprise library configuration console (installed the latest one from visual studio gallery) and trying to same, always was getting the following error message (even if I mentioned false for the “Track requests” and “use blob execution lease”):

“The application could not save the configuration information to the configuration file. Please try to save the configuration to a different file.
Error message : Required attribute 'advancedOptions' not found.”

Are the fields under the “advanced options” section mandatory?

2. Can I use the wasabi for tracking and scaling an application running in dev-fabric i.e. the local azure compute emulator? Actually currently we are facing some issue in using our azure account so was trying to use the block for watching an application running locally in the azure compute emulator. Actually I have this concern because while defining the service model xml I found that the details like subscriptionid, certificatethumbprint , etc to be mentioned in the subscription element are mandatory. If it is possible to test the wasabi to scaling an application locally then please let me know how to achieve the same, may be through some code/config snippets or any online article or blog.

3. I have installed and made reference to the application block using NuGet. But the issue is every time I need to use the application block in my different projects I have to be online and install the concerned package again and again. Because the installation of package happens locally to the project to which it is referred. And sometime because of folder structure created by the block, the file/dll name becomes too large.
Waiting for your response.
Thanks in advance,
Rahul (Rahul_bandopadhyaya@infosys.com)
Bangalore, INDIA

Azure currently allows for an updgrade option where you can upgrade an existing delpoyment but if there are changes to the ServiceDefinition config, then the upgrade fails with a Dr.Watson. If the change to the Definition needs a Suspend, delete, re-create cycle for deployment, the Azure Deployment mechanism(both on my VS2010 publish mechanism and on the Fabric Controller) should warn me of the same - by comparing old and new ServiceDefinition.csdef; which it doesn't. Further this leads me to request that it must permit us to separately upload ServiceDefinitions from Project files and not ask for the whole package during upgrades.

One of the differences between VMs and physical machines is that you cannot see what's going on when RDP doesn't work, for example when the machine has locked up or when it is booting.

It would be great to be able to get a screenshot of the current state, a bit like in HyperV server.

This would help us diagnose problems.

For example, the other day I was worried that one of my VMs was taking ages to boot up. It turns out it was doing a Windows Update before RDP was available.

If I could see a screenshot, I wouldn't have accidentally rebooted it!

Currently it is only possible to add only new VMs to DC either through management API or powershell.

For example there is a VM, which i want to join to DC running in the same VNET and in azure IaaS. There is no way we can do that either from API or Powershell, VM needs to be added to DC manually by specifying DNS IP in IPV4 config.

It is alway important to update existing machines that are running in work group to be added to DC and VNET without bringing them down.
Also it would be useful for managing and automating them through code.

Currently we cannot use the Storage Emulator because when we start attempting to upload blobs from multiple threads we will occasionally (and in one case very consistently) get generic 500 Internal Server errors. Looking at the logs for the emulator it appears to be getting into a SQL deadlock with itself and the 500 error is coming from the the request that got picked as the deadlock. A less generic error would at least allow us to add it to our retry policies (adding a generic 500 error to the retry policy seems like a bad idea). Even better would be to fix it, I haven't dug into the stored procs that are being called and deadlocking but it seems odd that this would be happening.