I see. If that's only for development however, how about just blindly trying to load the cached assembly if it's there, catch any exception and if an error happens, just discard the assembly and build a new one from scratch?
The problem here is that your definition of "same" is based on shape of the types, and CLR doesn't have anything built in to help you decide if it's going to be safe or not ahead of time. @K -- Krzysztof Kozmic On Tuesday, 19 March 2013 at 9:04 AM, Jean-Claude Viau wrote: > That's what we are trying to do. If the load in cache fail, create a new > cache. We just want to be sure that catching those 5 exceptions cover all the > failure use-case. Also, we want to ensure that if there's no exception when > calling LoadAssemblyIntoCache, there wont see issue/exception at runtime > later. > > We are also using assembly version. The cached assembly have a version and it > must match our product version otherwise we create a new cache. This works > well for released product but in development we wont change all assemblies > version on each changes that break the cache. That would be error prone and > would add more step to the development process. In fact, we want the caching > to be as transparent as possible. > > On Friday, March 15, 2013 9:00:04 PM UTC-4, Krzysztof Koźmic wrote: > > If that's just for development, why not try loading and if it fails create > > anew? > > Normally I would recommend inspecting assembly version and make decision > > based on that, not sure how rapidly your can make it work in development > > Krzysztof Kozmic > > sent from my phone > > On 16 Mar 2013 07:55, "Jean-Claude Viau" <jcv...@gmail.com (javascript:)> > > wrote: > > > That's what we are trying to accomplish, when we detect that the assembly > > > isnt compatible with the cache we want to delete it. We need to support > > > this because we are enabling the cache while developing and proxied types > > > could changes. In those case we want to be sure that we don't introduce > > > more issue in our development phase (e.g. crashed because of proxy, > > > delete your cache). It could seems overkill to have caching in > > > development but without the caching, starting the application in debug > > > take way too much time (because of the proxy). > > > > > > > > > Le jeudi 14 mars 2013 23:36:40 UTC-4, Krzysztof Koźmic a écrit : > > > > If the application assembly changes you shouldn't try to reuse the > > > > proxy cache. It's safer that way, I'm sure there are other failure > > > > scenarios than the ones you listed. > > > > Krzysztof Kozmic > > > > sent from my phone > > > > On 14 Mar 2013 17:00, "Jean-Claude Viau" <jcv...@gmail.com> wrote: > > > > > Hi, > > > > > > > > > > I am in the process of using Proxy caching and would like to > > > > > understand potential issue/exception that can occur. By doing some > > > > > test I found 5 exceptions that occurs when calling > > > > > LoadAssemblyIntoCache. Happens when there's a mismatch between the > > > > > cached type and actual type or with dependencies (assembly). I would > > > > > like to know if we missed some use-case and if there some exception > > > > > that can occur elsewhere (not in LoadAssemblyIntoCache call) ? > > > > > > > > > > Exception 1 - SerializationException > > > > > Occur when a method/property has been removed from a proxied type, it > > > > > raise this exception with this description : Cannot get the member > > > > > 'RemovedMethod'. > > > > > > > > > > Exception 2 - TypeLoadException > > > > > Occur when a method/property is added to a proxied type, it raise > > > > > this exception with this description : Method 'NewMethod' in type > > > > > 'xProxy' from assembly 'CachedProxiesAssembly' does not have an > > > > > implementation. > > > > > > > > > > Exception 3 - MissingMethodException > > > > > Occur when a method/property signature has been changed in a proxied > > > > > type (e.g. return type, argument type, number of arguments, ...) > > > > > > > > > > Exception 4/5 - FileLoadException / > > > > > TargetInvocationException(InnerException:FileNotFoundException) > > > > > Occur when there's a mismatch between cached type dependencies > > > > > (assemblies) version and current assemblies version (e.g. version of > > > > > Castle.Core). > > > > > > > > > > Thanks > > > > > Jean-Claude Viau > > > > > -- > > > > > You received this message because you are subscribed to the Google > > > > > Groups "Castle Project Users" group. > > > > > To unsubscribe from this group and stop receiving emails from it, > > > > > send an email to castle-project-users+unsubscr...@googlegroups.com. > > > > > To post to this group, send email to castle-pro...@googlegroups.com. > > > > > Visit this group at > > > > > http://groups.google.com/group/castle-project-users?hl=en. > > > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "Castle Project Users" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to castle-project-users+unsubscr...@googlegroups.com (javascript:). > > > To post to this group, send email to castle-pro...@googlegroups.com > > > (javascript:). > > > Visit this group at > > > http://groups.google.com/group/castle-project-users?hl=en. > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to castle-project-users+unsubscr...@googlegroups.com > (mailto:castle-project-users+unsubscr...@googlegroups.com). > To post to this group, send email to castle-project-users@googlegroups.com > (mailto:castle-project-users@googlegroups.com). > Visit this group at http://groups.google.com/group/castle-project-users?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to castle-project-users+unsubscr...@googlegroups.com. To post to this group, send email to castle-project-users@googlegroups.com. Visit this group at http://groups.google.com/group/castle-project-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
