David Kennedy’s Tech Ramblings

Just another WordPress.com weblog

Windows AppFabric Beta 2 Cache Configuration March 3, 2010

Filed under: AppFabric,Cache,Dublin,Velocity — dotnetdave @ 1:57 am

Being only two days old there is little information out there at the time of this writing. By starting with Beta 1 configuration samples and working with Reflector to inspect the Microsoft.ApplicationServer.Caching.Core and Microsoft.ApplicationServer.Caching.Client assemblies I was able to make the necessary changes so that the configuration xml lines up with the associated configuration class. I ended up with the following.


<section name="dataCacheClient"
Microsoft.ApplicationServer.Caching.Core, Version=, Culture=neutral,




This minimalist configuration was enough to get me started with simple ‘Add’ and ‘Get’ operations against the cache.

var factory = new DataCacheFactory();
cache = factory.GetCache("default");


VS2010 Repair after AppFabric Beta 2 / .NET 4.0 RC install

Filed under: AppFabric,Cache,Dublin,Velocity — dotnetdave @ 12:56 am

I attempted another complete repair of the VS RC, and this time it completed successfully, restoring it to working order and allowing me to continue with looking into the new AppFabric.

image image

If you have similar problems I’d recommend this sledge hammer approach as its likely going to be much quicker than a manual fix given the nature of beta releases.


Now to kick around using the cache finally!


VS 2010 killed after installing appFabric Beta 2 March 2, 2010

Filed under: Uncategorized — dotnetdave @ 6:58 am

I cannot be sure whether it was the AppFabric itself, or the .NET Framework 4.0 RC that caused this, but visual studio has now ‘forgotten’ about the 4.0 framework versions (of which I have two installed, both beta and RC). It now throws the following whenever an existing project is opened or a new one is created.


The error reports as:

A problem occurred while trying to set the "References" parameter for the IDE’s in-process compiler. Error HRESULT E_FAIL has been returned from a call to a COM component.

It simply does not offer the 4.0 target frameworks against a project, despite existing.

image image

I have attempted a repair of the 2010 installation with no success. Hopefully I’ll crack this tomorrow and can move on with using the AppFabric Distributed Cache.


appFabric Beta 2 Distributed Cache Powershell Admin

Filed under: AppFabric,Cache,Velocity — dotnetdave @ 5:52 am

My difficulties with the associated powershell commands were simply due to lack of knowledge on my part. I am now aware of the new module arrangement for powershell 2 as explained here. Clearly I was looking not only in the wrong place, but for the wrong assembly. With the new arrangement it is no longer necessary to kick up a custom powershell console with a consolefile as it was in version 1.


Simply starting powershell 2 with the ‘-ImportSystemModules’ option will load all the modules installed on the system, including ‘DistributedCacheAdministration’ and ‘DistributedCacheConfiguration’. I was then able to administer the cache cluster (if you can call it a cluster with only 1 node!) as follows:




Happy days!🙂


Server AppFabric Beta 2 Configuration

Filed under: AppFabric,Cache,Dublin,Velocity — dotnetdave @ 1:21 am

Following the installation as outlined in my previous blog post, I find myself presented with the following configuration wizard:


In my case I wish to investigate the monitoring capability of AppFabric so I’m going to check to set the monitoring configuration, with a SqlClient as the monitoring provider. I filled the configure form and confirmed the change as follows:

image image

If you had installed caching with the Beta 1 installation you may receive the following message as I did:


To accommodate any schema changes, I used osql to drop and recreate the empty ApplicationServerExtensions database:


If you dropped and recreated the database in the previous step, you may receive warnings similar to the following:

image Close this configure form by clicking ‘Cancel’.

After selecting the ‘sqlStoreProvider’ for persistence, click ‘Configure’ to access its settings. Complete this in the same manner as for monitoring. In my case I received the following warning:


After closing the persistence configuration form, click ‘Next’ to start the services and progress to the caching service configuration. Under Caching Service Configuration I selected to store the cache configuration in XML, though you may choose to store it in a SQL Server as an alternative. Create a network share and enter it on the form:


In the following ‘Cache Node’ step, customise port settings if desired. I accepted the defaults and checked to add firewall exceptions before clicking ‘Next’ to proceed:

image image

At this point the configuration is complete. In my case it seems that the management commandlets have not been installed and are unavailable. In the meantime, by starting the ‘AppFabric Caching Service’ we can see that the distributed caching service is now up and running on our configured ports.

M:\>nmap -p 22233-22236 saudev99 -P0

Starting Nmap 5.21 ( http://nmap.org ) at
Nmap scan report for saudev99 (
Host is up (0.0094s latency).
22233/tcp open  unknown
22234/tcp open  unknown
22235/tcp open  unknown
22236/tcp open  unknown
MAC Address: 00:0C:29:D0:D7:7B (VMware)


Now I need to get the powershell console working for this as well. It seems that the Beta 2 equivalent of the Microsoft.Data.Caching.Commands snap-in has not been installed. By referencing Beta 1 I identified that this namespace is defined within the AdminPS.dll assembly, which does not seem to exist in the Beta 2 installation. I’ll have a crack at using the Beta 1 assembly with Beta 2 for the powershell commandlets once I source this DLL from the older installer.


In my next post I’ll be making use of the cache from within .NET applications/


Installing Server AppFabric Beta 2 March 1, 2010

Filed under: AppFabric,Cache,Dublin,Velocity — dotnetdave @ 6:56 am

As is often the case with beta releases, the web is packed full of marketing material touting the capabilities and benefits of AppFabric whilst lacking useful deployment details. Since I’ve been unable to find a reasonable walk-through of this process for the new beta 2 release I thought I’d better blog it. Here’s the basic steps I followed:

  • Start with a clean install of Windows Server 2008 R2
  • Add the ‘Application Server’ and ‘Web Server (IIS) Roles
  • Run the Web Platform Installer 2.0
  • Select the ‘Options’ link at bottom left
  • Check the ‘Enterprise’ Checkbox and click OK
  • Now under the ‘Enterprise’ section there should be an option to install ‘Windows Server AppFabric Beta 1’. If this option is not listed, verify that you are running a supported windows OS. If you are running on a pre-R2 server 2008 you will need to patch your system accordingly. Use of this tool will take care of several pre-requisites to save you the time


  • From the windows programs console, uninstall the Beta 1 which we just installed. NOTE: Due to Microsoft’s schizophrenic product naming it is not apparent WHICH program should be uninstalled. In short, ‘Windows Server AppFabric’ == ‘Application Server Extensions for .NET 4’. Inspecting the WPI logfile (%windir%\logs\cbs\cbs.log and tracking the installation process eventually led me to the actual executable performing this installation. Re-use this to uninstall the product since I have NFI what this is listed under in the programs listing. You will find this in a directory similar to the following:

C:\Users\MyUserName\AppData\Local\Microsoft\Web Platform Installer\installers\AppFabric7Setup\be56d6c05160e27dbc996a1b2b7156e2037eefe6\AseSetup_amd64_6.1.exe

  • Upgrade the .NET 4.0 installation from Beta 2 to RC. (AppFabric Beta 1 requires .NET 4.0 Beta 2, AppFabric Beta 2 requires .NET 4.0 RC). This can be simply installed over-the-top and is available from the following:


  • Download and install Windows Server AppFabric Beta 2

NOTE: Repair the installation of ‘Microsoft .NET Framework 4 Client Profile’ at this point as per the last step of this guide to avoid the following problem



  • During the select features step, be sure to check ‘Cache Client’ and ‘Cache Administration’


  • I then received the following pre-requisite problems, both indicating that there is some sort of problem with the .NET 4.0 installation following the ‘upgrade’ from Beta to RC. The referenced help page describes this as ‘Setup has detected that the upgrade from .NET Framework 4 Beta 2 to .NET Framework 4 RC (or beyond) did not fully complete. This could result in an error in enabling non-HTTP activation.’


  • After following the instruction to repair the installation of ‘Microsoft .NET Framework 4 Client Profile’ and restarting, I was able to complete the installation. (I’m very surprised as those help files are usually entirely useless and do nothing to help the problem.)


  • Mission accomplished! I’ll blog my experiences configuring and playing with this over the next couple of days.

Web Platform Installer, not as simple as indicated! February 24, 2010

Filed under: Uncategorized — dotnetdave @ 6:54 am

Well, after hearing about the WPI on several podcasts & reading about it on a few websites I decided to give it a crack. This utility is supposed to make deploying web application servers a simple click-through process. Now I wasn’t being particularly unrealistic in my expectations; no installer can guarantee success in all environments.


So I started with a brand new Server 2008 R2 machine (running under ESXi). No roles, no features, just a base-bones installation of R2 Datacenter.


I then added both the “Application Server” and “Web Server (IIS)” roles.


Next I kicked up the Web Platform Installer. Now it can’t get much simpler than a clean installation of the recommended server product (R2). I didn’t expect any dramas.


But to my surprise, WPI failed to install SQL Server Express 2008 SP1. I was forced to pull this down & install it separately before continuing with WPI.


Fail again MS, Fail again.