Exceptions with cached types from dynamically built modules

[davidjrh]

The following exception has been observed on a DNN instance that uses the IFrame module, that is built dynamically https://github.com/DNNCommunity/DNN.IFrame

2016-01-13 10:04:20,574 [RD000XXXXYYYY][Thread:89][ERROR] DotNetNuke.Providers.RedisCachingProvider.RedisCachingProvider - System.IO.FileNotFoundException: Could not load file or assembly 'App_SubCode_IFrame.pxj5ui1q, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
File name: 'App_SubCode_IFrame.pxj5ui1q, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
   at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean forIntrospection)
   at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
   at System.Reflection.Assembly.Load(String assemblyString)
   at System.UnitySerializationHolder.GetRealObject(StreamingContext context)
   at System.Runtime.Serialization.ObjectManager.ResolveObjectReference(ObjectHolder holder)
   at System.Runtime.Serialization.ObjectManager.DoFixups()
   at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler handler, __BinaryParser serParser, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
   at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream)
   at DotNetNuke.Providers.RedisCachingProvider.RedisCachingProvider.Deserialize[T](String base64String)
   at DotNetNuke.Providers.RedisCachingProvider.RedisCachingProvider.GetItem(String key)

This sounds like that while trying to deserialize the object stored in the Redis cache, the type is not available on the current app domain, something that can happen if a module uses “dynamic” module compilation and stores an object on the Redis cache or, for example, if the new type no longer exists because the host dependencies were updated (i.e. by a Windows Update). After an application restart causing dynamic assembly rebuild, the old type stored on the Redis cache is of an assembly that no longer exists, because the type is now in another dynamically built assembly.

I think this case can be mitigated by catching the exception, so the GetItem flow would automatically update the cache with the new value immediately.