05 October 2014 Reflection, Assembly, .NET Robert Muehsig

Last week I worked on an old ASP.NET WebApp. The WebApp uses normal Resource Files for localization and it worked well in our Development-Environment. We could switch between Debug and Release Mode with IIS Express and the application picked the correct resources.

Problem: On IIS with Release no resources were found

I deployed the WebApp to our Staging-Environment and all Localized Texts were not loaded. I redeployed it with Debug and now everything was fine.

Problem Source: Assembly.GetCallingAssembly()

It took me a while and I needed to pull out some decade old code to see how the localization was done in this project. Root problem was this line: “Assembly.GetCallingAssembly”. This code line was hidden in a “base-framework” (with controls and stuff). The idea was that the base framework would load the “calling” assembly and use this as the localization source for the ResourceManager.

Why did it break only on IIS with Release mode?

From Assembly.GetCallingAssembly-MSDN:

If the method that calls the GetCallingAssembly method is expanded inline by the just-in-time (JIT) compiler, or if its caller is expanded inline, the assembly that is returned by GetCallingAssembly may differ unexpectedly.

In IIS Express and IIS with Debug mode everything worked as expected, but on IIS with Release “Assembly.GetCallingAssembly” returned the System.Web.dll instead of our own assemblies with the correct localizations.

TL;DR

Don’t use Assembly.GetCallingAssembly for such scenarios. Thanks to this blogpost I fixed the bug.


Written by Robert Muehsig

Software Developer - from Dresden, Germany, now living & working in Switzerland. Microsoft MVP & Web Geek.
Other Projects: ExpensiveMeeting | EinKofferVollerReisen.de


blog comments powered by Disqus