Typical - just as I get an AppFabric Beta 1 caching cluster up and running for Edge UG this month, they release Beta 2!
This is, by all accounts, now a feature complete release for v1.0 with the RTM expected in Q3 this year. There is, however, no Go Live licence here, unlike Visual Studio. Let's take a look at AppFabric B2 and see what's changed (from a caching perspective)...
What's New in Installation
First of all, this release is aligned with the Release Candidate of .NET 4.0 and VS2010, so the dependency on the .NET Framework is moved up from the beta to the .NET 4.0 Release Candidate. Note that if you're removing the .NET 4.0 Beta in order to install AppFabric, you need to do this in Control Panel|Programs and Features, and uninstall the .NET 4.0 Framework Extended first, then the the .NET 4.0 Client Profile.
The installer seems to have had quite a bit of time spent on it for this release.
The set of features to install is largely the same as we saw in Beta 1, with the addition of an administration piece for the Dublin workflow component.
Post-installation, the AppFabric caching service has been renamed and no longer refers to the Velocity codename; it also now is not marked as a CTP (unlike the caching service in Appfabric Beta 1 which still showed as CTP4).
Installation and configuration have been decoupled into two separate wizards, which should make it possible to reconfigure a cluster without having to un- and re-install.The configuration wizard can be started at the end of installation, or separately from the Start menu.
What's New in Configuration
As before when configuring the caching piece you have to decide whether to store configuration information in SQL Server or using XML and a network share. There's still no guidance on when you should use one or the other, although included in this release is a comprehensive help file.
Selecting the SQL Server provider and clicking the Configure button opens this sub-dialog where you can build up the connection string to the configuration database. It's now explicit that if you enter the name of a database that doesn't exist and select the 'Create...' checkbox then the configurator will go and create the database for you. If you're adding a server to an existing cluster, then the 'Register...' checkbox is the one to select; if you unselect both checkboxes you lose the ability to enter any connection string information. However there seems to be a slight bug in that whether you create a new database from scratch or register a server to an existing database, when you return to the main configuration screen you can still choose whether you are creating a new cluster or joining an existing cluster.
As before, the configurator allows you set the size of the cluster to optimise the clusters' performance. The help file states that 'once you set the cluster size during configuration, you cannot change it later', however it's unclear how this fits in with the ability to re-run the configurator from the Start menu.
As I run my Velocity VM cluster with Windows Firewall disabled, I'm pleased to see that the Cache Node configuration page now detects when the firewall is disabled and accordingly disables the firewall exceptions checkboxes. This is a change to Beta 1 where the Velocity installer log would register a warning if the firewall was disabled.
What's New in Powershell
In a change from previous installs, there doesn't seem to be a Velocity Administration Powershell console installed by default; to access the Velocity Powershell commands you need to run up Powershell and then run 'import-module DistributedCacheAdministration'. Or you can add it to your Powershell profile - run 'get-help profiles' for details on doing this.
Looking at the list of Powershell commands available it seems that, unforgivably, there's still no commandlets for managing regions.The Install-Data and Install-Bits cmdlets that were in Beta 1 have disappeared.
A new feature is that it seems you can now use Powershell on any server with the Velocity cmdlets installed to manage any Velocity cluster, by using the 'Use-CacheCluster' cmdlet with a connection string to a configuration store (though the documentation talks about a connection string which implies this only works with the SQL Server provider). This cmdlet sets the context of subsequent commands e.g. Start-CacheCluster, Restart-CacheCluster. This enables you to manage multiple clusters from a server that isn't in any cluster. If you're running Use-CacheCluster on a server that is inside a cluster and has Cache Administration (from the installer) set up, you don't need to use any parameters, the current cluster is implied.
What's New in Client Configuration
The assemblies that you need to add to a project to use Velocity have been renamed, to Microsoft.ApplicationServer.Caching.Core.dll and Microsoft.ApplicationServer.Caching.Client.dll (in Windows\System32\AppFabric). The namespace has changed again, to Microsoft.ApplicationServer.Caching. And the requirement to also reference the Fabric assemblies has been removed, so there's only two references to add which makes the whole thing seem much cleaner.
The MSDN article on setting up the client environment states that there is a problem with referencing these DLLs as Visual Studio is unable to browse to Windows\System32\AppFabric, and that you need to hand-edit the project file to include these references. This seems to be incorrect, as I've just done it - I suspect that this may be due to the fact I'm running Visual Studio under an account which is an administrator on the server and thus has access to everything.
A couple of the old annoyances when writing client code are still there:
The installer seems to have had quite a bit of time spent on it for this release.
Installation and configuration have been decoupled into two separate wizards, which should make it possible to reconfigure a cluster without having to un- and re-install.The configuration wizard can be started at the end of installation, or separately from the Start menu.
What's New in Configuration
As before, the configurator allows you set the size of the cluster to optimise the clusters' performance. The help file states that 'once you set the cluster size during configuration, you cannot change it later', however it's unclear how this fits in with the ability to re-run the configurator from the Start menu.
As I run my Velocity VM cluster with Windows Firewall disabled, I'm pleased to see that the Cache Node configuration page now detects when the firewall is disabled and accordingly disables the firewall exceptions checkboxes. This is a change to Beta 1 where the Velocity installer log would register a warning if the firewall was disabled.
What's New in Powershell
In a change from previous installs, there doesn't seem to be a Velocity Administration Powershell console installed by default; to access the Velocity Powershell commands you need to run up Powershell and then run 'import-module DistributedCacheAdministration'. Or you can add it to your Powershell profile - run 'get-help profiles' for details on doing this.
Looking at the list of Powershell commands available it seems that, unforgivably, there's still no commandlets for managing regions.The Install-Data and Install-Bits cmdlets that were in Beta 1 have disappeared.
A new feature is that it seems you can now use Powershell on any server with the Velocity cmdlets installed to manage any Velocity cluster, by using the 'Use-CacheCluster' cmdlet with a connection string to a configuration store (though the documentation talks about a connection string which implies this only works with the SQL Server provider). This cmdlet sets the context of subsequent commands e.g. Start-CacheCluster, Restart-CacheCluster. This enables you to manage multiple clusters from a server that isn't in any cluster. If you're running Use-CacheCluster on a server that is inside a cluster and has Cache Administration (from the installer) set up, you don't need to use any parameters, the current cluster is implied.
What's New in Client Configuration
The assemblies that you need to add to a project to use Velocity have been renamed, to Microsoft.ApplicationServer.Caching.Core.dll and Microsoft.ApplicationServer.Caching.Client.dll (in Windows\System32\AppFabric). The namespace has changed again, to Microsoft.ApplicationServer.Caching. And the requirement to also reference the Fabric assemblies has been removed, so there's only two references to add which makes the whole thing seem much cleaner.
The MSDN article on setting up the client environment states that there is a problem with referencing these DLLs as Visual Studio is unable to browse to Windows\System32\AppFabric, and that you need to hand-edit the project file to include these references. This seems to be incorrect, as I've just done it - I suspect that this may be due to the fact I'm running Visual Studio under an account which is an administrator on the server and thus has access to everything.
A couple of the old annoyances when writing client code are still there:
- DataCacheFactory.GetCache is still not a static method, you still need to new up a DataCacheFactory.
- Some of the code around using DataCacheServerEndpoints seems to have been refactored a little bit, but it still runs on an array, not a List(Of DataCacheServerEndPoint). But you can, of course, still get round this by using a List(Of DataCacheServerEndpoint) and then calling .ToArray on it.
No comments:
Post a Comment