I’ve been scrathing my nerves trying to get around an Azure Cache relates situation that I came across in one of my recent projects.

There are multiple caching scenarios and options available for Azure, but I’m going to talk about this in a different post. For now, just keep in mind that I decided to go with a dedicated co-located role for caching, which basically means a different VM that serves all the caching request. I’ve also configured the caching clients (all the pieces of code that request cache) to use the caching cluster configured on that Azure Caching Role.

In order to configure that particulat scenario, you have several options available for importing the references (.dlls) and configuring your configuration files (mostly web.config sections), but the most common and simple usage scenario is to go with the NuGet Package Manager and install the Windows Azure Caching package.

As of 31st of July, the latest version of WAC package is 2.1.0.0. Moreover, if you search around your favourite search engine a little, you’ll come across an article mentioning the WAC package and that you should configure the NuGet package Manager to show pre-release versions of the package as well. This article was posted somewhere in late-June. IMHO, once I saw 2.1.0.0 was already a stable release, I was amazed and pleased by the hard work of the Azure team at Microsoft.

After installing the package, I got this strange exception in my code:

There is a temporary failure.     Please retry later.  (One or more specified cache servers are unavailable, which could be caused by busy network or servers.  For on-premises cache clusters, also verify the following conditions. Ensure that security permission has  been granted for this client account, and check that the AppFabric Caching Service is allowed through the  firewall on all cache hosts. Also the MaxBufferSize on the server must be greater than or equal to the  serialized object size sent from the client.). Additional Information : The client was trying to communicate  with the server: net.tcp://MvcWebRole1:24233.

The inner exception stated:

No such host is known

Unfortunatelly, both exceptions are extremely generic, considering the cache cluster name is configured corrently and running smoothly (you can always use the Azure emulator to confirm). However, the code just decided not to run.

After a little more research, I found out that MS also announced the new SDK, namely Windows Azure SDK 2.1. However, this time they didn’t do all the usual marketing campains for some reason that I’m not really aware of. I also found out that the latest release of the WAC package only works with that specific SDK (apparently reading the NuGet package description is required :-) ), so here I am, running this line of script in the Package Manager console and making everything work:

Install-Package Microsoft.WindowsAzure.Caching -Version 2.0.0.0

I hope this post finds you in good peace and helps you solve similar problems in a shorter period of time!

A.

P.S.: sometimes (random cases), the script for installing the WAC package (v. 2.0.0.0), after uninstalling WAC 2.1.0.0 fails. Don’t worry though, since the web.config file is correctly modified by the WAC installer and all the references exist and are correctly included in the project.

One other situation I recently came across was regarding WIF and the pipeline security applied to it. Basically, due to up-scaling a project from one server (I know…) to multiple-instances, the app kept going into infinite redirect loops (HTTP 302), thus not allowing users to wander around the app. The case like this:

1. The user first visits the page

2. The user clicks anything in the page

3. The app goes into infinite 302.

The situation was cause by the security mechanisms the make the ASP.NET session authentication secure. Basically, by default, the DPAPI security providers are used. This basically states that for every single new session, a random key is generated that the user can wander around. That key is normally kept in the session providers, but is related to the keys used by the machine. Obviously, in a webfarm scenario (such as a multi-instance cloud service), DPAPI is useless and causes a CryptographicException to be thrown, since the FedAuth cookie gets encrypted by one machine and when you redo a request to your app, the cookie can no longer we decrypted.

If, for any case, you have a custom error page and if you, like in my case, must have the security mechanisms inside a Master page and mostly if the Error page inherits the Master page, you will, like me, get an infinite redirect loop (302).

The solution to this is to configure (using the web.config file) your IIS machines to use another security pipeline mechanism, such as MachineKey encryption. Moreover, it is obviously required to configure a static machine key and validation key, yet most Google-related results for this situation fail to remember that such a setting is required. Otherwise, the different machines in the web farm still get different keys and the FedAuth cookie won’t decrypted, failing in the CryptographicException all over again.

The required configuration for web.config for replacing your DPAPI security mechanisms with MachineKey cryptography is:

<securityTokenHandlers>

<add type=”System.IdentityModel.Services.Tokens.MachineKeySessionSecurityTokenHandler, System.IdentityModel.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ />

<remove type=”System.IdentityModel.Tokens.SessionSecurityTokenHandler, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089″ />

</securityTokenHandlers>

As for the machine key, you have to choose an appropiate key size (only HEXA-DEC chars), as mentioned on this MSDN article on machinekey configuration in ASP.NET 2.0 (I know it’s old, but it’s still valid for ASP.NET 4.0).

Choose an appropriate key size. The recommended key lengths are as follows:

  • For SHA1, set the validationKey to 64 bytes (128 hexadecimal characters).
  • For AES, set the decryptionKey to 32 bytes (64 hexadecimal characters).
  • For 3DES, set the decryptionKey to 24 bytes (48 hexadecimal characters).

A.

After attending last year’s ITCamp oganized in Cluj-Napoca, Romania, I was definite that I would attend this year again, even though I will have to leave for Cluj-Napoca on my b-day party (which I absolutely hate, because in the last 6 years, faith made it like that the my b-day would always find in a foreign city or country).

Anyway, back to ITCamp 2013. ITCamp is a developer and sysadmin conference where Microsoft technologies (and related to Microsoft technologies – such as Linux :) ) are presented by industry experts (technology gurus, MVPs, Microsoft Evangelists, ex-Microsoft employees, technology enthusiasts etc.). On their agenda you will find things like ‘Building Elastic, Autoscalable Solutions with Windows Azure‘, ‘Developing for Windows 8 with F# and WebSharper‘, ‘MVC – Common pitfalls and how to resolve them‘, ‘Transact-SQL from 0 to SQL Server 2012‘, ‘Kinect for Windows – Designing Software for Gesture & Voice Controlled User Interfaces‘ and so many other cool things you might actually be interested in!

Last but definitely not least, Richard Campbell and Tim Huckaby are also among the speakers!

Do google ITCamp or go straight to http://itcamp.ro, check the agenda out and register asap: seats are already filling up :)

Alex

I just had this scenario, when I would add whatever action control on a page and set its PostBackUrl property to another page. I would do this because I wanted to send some data from the current page (more like a view, where you input stuff) to another page via the POST method. However, for some super perculiar reason, I kept missing something, because whenever I would hit the control that did the POST action via the PostBackUrl property setting, the Request.RequestType that was incomming to the destination page was GET instead. Obviously, the Request.Form property didn’t containt any collections from which to extract the expected data from. After loosing precious time around this matter, I just realized that the ASP.NET WebForm template I was building the project upon had the preview of the FriendlyUrls NuGet package installed. What is FriendlyUrls? Basically, it’s a Microsoft signed NuGet package that handles your website in such a manner that your URLs become friendly: e.g. http://localhost/Default.aspx can also be visited through http://localhost/Default (which apparently is friendly). Don’t get me wrong, it’s not that FriendlyUrls has something against Posting via PostBackUrl property. It’s just that the template I was building the project upon had the 1.0.0-alpha1 version of FriendlyUrls installed rather than a final release of the package. After updating the package to its final release, I was able to POST via forms using the PostBackUrl property just fine. Hope this helps other outside there! A.