regarding the usage of WASABi (auto scaling block)

Topics: Building and extending application blocks, Enterprise Library Core
Nov 10, 2011 at 8:26 AM


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 (

Bangalore, INDIA

Nov 12, 2011 at 1:58 AM

Hi Rahul,

Thanks for trying out the Windows Azure Scaling Application Block Beta!  


The error message you are seeing looks like a known issue.  From the ReadMe file:

"To configure the Autoscaling block settings in the  Enterprise Library configuration tool, the Advanced Options settings must be supplied with non-default values. If no such values are specified, the next time the configuration is loaded, the tool does not allow you to save the configuration file." 

If you check, the configuration file is actually saved despite the message. 


You should be able to use WASABi with compute emulator.  I would recommend watching the webcast Autoscaling Windows Azure applications if you haven't already.
Also, read the readme file under the NuGet download folder located under {your project folder}\packages\EnterpriseLibrary.WindowsAzure.Autoscaling.Preview.5.0.1007.0\content\ReadMe.txt.

You can also download the source code by downloading the Enterprise Library 5.0 - Windows Azure Integration Pack Source Code - Beta - 5.0.1007.0 (search for Wasabi is best).
This will bring down Enterprise Library 5.0 Windows Azure Integration Pack - which contains a ConsoleAutoScaler host project similar to the webcast.

Another good article is First Look: Scaling with the Windows Azure Autoscaling Block.


Once you've downloaded the Block with NuGet you can just copy the assemblies out of the packages folder to a common drive and reference them directly in case you don't have internet access.  Of course, you lose some of the ease of maintenance that NuGet gives you and it makes it easy to forget to reference an assembly.  You're right, though: the MAX_PATH limitation can cause headaches when trying to impose a "nice" directory structure.


Randy Levy
Enterprise Library support engineer

Nov 14, 2011 at 4:32 AM
Edited Nov 15, 2011 at 11:27 AM

Thanks a lot for this valuable information. Let me go through it.

Nov 15, 2011 at 9:37 AM

I have gone through that video in channel-9. Actually this session talks about hosting the wasabi in a role which is running in dev-fabric (compute-emulator). But my requirement is a little different, I need to watch and scale an application running in compute-emulator instead of Azure using the wasabi which is hosted in other worker role or console application.

Basically I will be using compute – emulator to host the target application to be scaled, not the host for wasabi. So can we use the wasabi to watch and scale an application which is running in compute-emulator (NOT in Azure) and if so how to achieve the same.




Nov 16, 2011 at 12:20 AM

If I understand you correctly then I don't think you can do exactly what you are thinking.

You can host WASABi in an on premises console application.  However, I don't believe that the compute emulator supports the Service Management API (which is what is used to scale).

If you ware still interested in more information you may want to download the available documentation:  

Randy Levy
Enterprise Library support engineer