0

When reflected information is required on a specific type, I often store the information (post retrieval and processing) on a private static field of whatever class I am doing the work. In the past, in certain situations, after some changes where made to the class, the statically cached reflection data would be stale (no longer reflected the class current metadata). The context being an ASP.net application, I would reset IIS or recycle the intended app pool and the data would now get retrieved correctly. Given that IIS automatically recycles the app pool if any changes are made to either the web.config or the bin folder, How was that cached data hanging around? In other words, How could I replicate that on an instance of IIS with standard configuration ?

The .net is question is .net framework 4.8. The IIS in question is IIS 10 on Windows 10 Professional.

The exact sequence of events as I understand it were: Class SomeBusinessService was decorated with MySpecialAttribute [MySpecial]. Dev runs the app on IIS. Dev makes a change to SomeBusinessService and adds a second attribute [MySecond] to the class. Dev builds solution on Visual Studio 2019. The output target is the actual folder where IIS runs from (thus changing the bin folder). When Dev runs the app again, the static field is already populated, thus old information is used.

SynBiotik
  • 441
  • 1
  • 5
  • 14
  • Metadata obtained via reflection is static and immutable. The code where you cache that data and the cached data itself should never be out of sync. So I doubt anyone can help explain why an impossible situation as you've described might have arisen. – Kirk Woll Jun 10 '22 at 19:56
  • @KirkWoll OP likely simply misunderstands type identity - it's tricky in ASP.Net when they reload part of the code on the fly - appdomain endup having multiple classes with the same simple name loaded from multiple assemblies causing major PITA for scenarios where object need types to be matching - obvious case - put data in session state and try to get it on page from updates source... same applies to the caching type info. That hot reload was hot mess from the beginning :) – Alexei Levenkov Jun 10 '22 at 20:35
  • Side note: you may want to find an official source for "IIS automatically recycles the app pool if **any** changes are made to ... the bin folder". – Alexei Levenkov Jun 10 '22 at 20:46
  • @KirkWoll I've added more info to the question. – SynBiotik Jun 10 '22 at 21:58
  • @AlexeiLevenkov is not that I don't understand type identity but it's fair to say that I know nothing of how hot reload works on IIS. – SynBiotik Jun 10 '22 at 22:00
  • 1
    @AlexeiLevenkov I don't know of an official source but I can find several posts on stack overflow as well as other stack exchange sites that refer to this behavior. Ex: https://stackoverflow.com/questions/302110/what-causes-an-application-pool-in-iis-to-recycle – SynBiotik Jun 10 '22 at 22:08
  • @SynBiotik the blog post linked from that answer looks like listing correct reasons (I've fixed up the link so it actually works) - pay close attention to the "The number of re-compilations (aspx, ascx or asax) exceeds the limit..." (https://learn.microsoft.com/en-us/archive/blogs/tess/asp-net-case-study-lost-session-variables-and-appdomain-recycles#:~:text=The%20number%20of%20re%2Dcompilations%20(aspx%2C%20ascx%20or%20asax)%20exceeds%20the%20limit). The other answer hint at that but I guess tracking info from 10+ years ago is tricky. – Alexei Levenkov Jun 10 '22 at 22:35

1 Answers1

0

The easiest way to replicate this behavior (which you misinterpret as "type information is updated") is to

  • have a simple class like class Foo{}
  • compile that class into two different assemblies (A1.dll, A2.dll)
  • load both assemblies to a process
  • create instances of Foo from each of the assemblies
  • use GetType to obtain the type for both instances
  • complain that types are different despite object built from the same source.
Alexei Levenkov
  • 98,904
  • 14
  • 127
  • 179