When working with AppFabric Caching features in an application (i.E. web service) hosted in IIS, you might experience following problem:
=== Pre-bind state information ===
LOG: User = Unknown
LOG: DisplayName = Microsoft.ApplicationServer.Caching.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
(Fully-specified)
LOG: Appbase = file:///D:/Tfs/ble/bla...
LOG: Initial PrivatePath = D:\Tfs\ble\bla\bin
Calling assembly : Jettware.System, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: D:\Tfs\ble\bla\web.config
LOG: Using host configuration file: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet.config
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Post-policy reference: Microsoft.ApplicationServer.Caching.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
Depending on the place in code where Caching objects are initialized, the same error can be detected as next snippet shows too:
FileNotFoundException:
C:\Windows\assembly\GAC_MSIL\Microsoft.ApplicationServer.Caching.Client\1.0.0.0__31bf3856ad364e35\Microsoft.ApplicationServer.Caching.Client.dll
Note that we have experienced the same problem with other libraries like Entity Framework. Anyhow there are several error messages which in fact indicates the same problem.
My favorite one is: “".. ‘localhost’ cannot be resolved”. This error would get the caller of web service operation which fails with one of exceptions shown above.
I always say “If you don’t know what is the problem, then the answer could be probably Kerberos.” Fortunately this time is not Kerberos in play :). It is much wars. :(
The real problem is however security or more precisely impersonation level. This can happen when your service allows or requires the impersonation and when impersonation is done.
For example, the exception can be caused by this code:
using (((WindowsIdentity)Thread.CurrentPrincipal.Identity).Impersonate())
{
new DataCacheFactory();
}
This code will enforce the thread to impersonate the thread user as a caller of an external service. In this case DistributedCacheService. Because the impersonated user is possibly not permitted to instantiate the cache object (do not ask me why), on eof exceptions shown above will be thrown.
Here the workaround to solve this problem:
The new DataCacheFactory has to be called not impersonated (with pool user) once and anywhere in the application domain. After this all other calls to all cache class constructors will work.
public class myclass
{
static myclass()
{
DataCacheFactory f = new DataCacheFactory();
}
public void myMethod
{
using (((WindowsIdentity)Thread.CurrentPrincipal.Identity).Impersonate())
{
new DataCacheFactory();
}
}
}
