During ASP.NET precompilation of our .NET 3.5 web application, various initialization is performed in type initializers. One of the type initializers throws a custom exception when the environment is incorrectly configured. However, when our custom exception is thrown, here is what the aspnet_compiler.exe tells us:
[exec] error ASPRUNTIME: Type is not resolved for member 'App.Project.CustomException,App.Project, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
[exec]
[exec] [SerializationException]: Type is not resolved for member 'App.Project.CustomException,App.Project, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
[exec] at System.Web.Compilation.BuildManagerHost.PrecompileApp(ClientBuildManagerCallback callback)
[exec] at System.Web.Compilation.ClientBuildManager.PrecompileApplication(ClientBuildManagerCallback callback, Boolean forceCleanBuild)
[exec] at System.Web.Compilation.ClientBuildManager.PrecompileApplication(ClientBuildManagerCallback callback)
[exec] at System.Web.Compilation.Precompiler.Main(String[] args)
Notice that no "real" stack trace information is included. However, when I change our code to throw an InvalidOperationException (instead of our custom exception), the stack trace is included correctly. (As an aside, our CustomException type is annotated with [Serializable]. When we remove the [Serializable] annotation, the aspnet_compiler.exe complains differently -- that our custom exception is not marked as such.)
Does anyone know why throwing a custom exception during ASP.NET precompilation is causing the secondary SerializationException? Why is it trying to serialize the exception? Similarly, why does using a BCL InvalidOperationException not cause the secondary SerializationException?
Could this be because the aspnet_compiler.exe is trying to do some sort of reflection on unexpected exceptions? (And therefore since it does not have our App.Project assembly loaded, it is unable to resolve the type?)