Recipe8.16.Determining Current appdomain Settings Information

Recipe 8.16. Determining Current appdomain Settings Information

Problem

You want to know about the current settings for the appdomain your code is executing in to help in debugging various issues with assembly loading, authorization issues, and startup problems.

Solution

Examine the properties of the appdomain.CurrentDomain.SetupInformation class to see the activation settings, the security information for the appdomain, associated file paths like code base and configuration files, assembly binding and policy settings, and load optimization and shadow copy settings. Get the appdomainSetup object with the current appdomain settings information like this:

 appdomainSetup info = appdomain.CurrentDomain.SetupInformation;

Now the ActivationArguments can be examined to find out things like the code base and full name of the appdomain as well as the corresponding ActivationData and ActivationContext information:

 Console.WriteLine("Current appdomain Properties:"); if (info.ActivationArguments != null) {     if (info.ActivationArguments.ApplicationIdentity != null)     {         Console.WriteLine("\tappdomain CodeBase: {0}",             info.ActivationArguments.ApplicationIdentity.CodeBase);         Console.WriteLine("\tappdomain Full Name: {0}",             info.ActivationArguments.ApplicationIdentity.FullName);     }     foreach (string data in info.ActivationArguments.ActivationData)     {         Console.WriteLine("\tActivation Data: {0}", data);     }     if (info.ActivationArguments.ActivationContext != null)     {         Console.WriteLine("\tappdomain Identity: {0}",             info.ActivationArguments.ActivationContext.Identity);     } }

The current values for the application base and name are available from their respective properties:

 Console.WriteLine("\tCurrent Application Base: {0}",     info.ApplicationBase); Console.WriteLine("\tCurrent Application Name: {0}",     info.ApplicationName);

To look at the security information for the application, see if the ApplicationTrust property of the appdomainSetup object is available. If it is, the identity full name, code base, granted permission set, and level of trust are available.

 if (info.ApplicationTrust != null) {     Console.WriteLine("\tSecurity Info for the Application:");     Console.WriteLine("\t\tApplication Identity CodeBase: {0}",         info.ApplicationTrust.ApplicationIdentity.CodeBase);     Console.WriteLine("\t\tApplication Identity FullName: {0}",         info.ApplicationTrust.ApplicationIdentity.FullName);     Console.WriteLine("\t\tDefaultGrantSet: {0}",         info.ApplicationTrust.DefaultGrantSet.ToXml());     Console.WriteLine("\t\tIs the application trusted to run: {0}",         info.ApplicationTrust.IsApplicationTrustedToRun); }

Some of the more general properties of the appdomain, like the shadow copy path, the path to the configuration file, and the path to the license file, are also available directly from the appdomainSetup object:

 Console.WriteLine("\tApplication Shadow Copy Path : {0}",     info.CachePath); Console.WriteLine("\tConfig File : {0}",     info.ConfigurationFile); Console.WriteLine("\tThe license file for this appdomain is located here: {0}",     info.LicenseFile);

Information about the assembly-loading constraints for the appdomain is also available, such as if the appdomain should probe the appbase or private bin path for assemblies when loading and what those paths are. It can be determined if the appdomain is allowing binding redirection, if it is allowing code to be downloaded, if it uses a publisher policy, and where dynamically generated assemblies are stored by looking at the DisallowBindingRedirects, DisallowCodeDownload, DisallowPublisherPolicy, and DynamicBase properties, respectively.

 Console.WriteLine("\tAssembly loading parameters:"); Console.WriteLine("\t\tIs probing allowed in appbase and private bin path? : {0}",     !info.DisallowApplicationBaseProbing); Console.WriteLine("\t\tPrivate Bin Path: {0}",     info.PrivateBinPath); if (info.PrivateBinPathProbe != null) {     if (info.PrivateBinPathProbe.Length > 0)         Console.WriteLine("\t\tExclude appbase from search path");     else         Console.WriteLine("\t\tInclude appbase in search path"); } Console.WriteLine("\t\tIs binding redirection allowed?: {0}",     !info.DisallowBindingRedirects); Console.WriteLine("\t\tIs code downloading allowed : {0}",     !info.DisallowCodeDownload); Console.WriteLine("\t\tIs publisher policy used? : {0}",     !info.DisallowPublisherPolicy); Console.WriteLine("\t\tDynamically generated files are stored at: {0}",     info.DynamicBase);

Finally, the loader optimization and shadow copy information can be retrieved from the LoaderOptimization, ShadowCopyDirectories, and ShadowCopyFiles properties:

 Console.WriteLine("\t\tLoader optimization: {0}",     info.LoaderOptimization.ToString()); Console.WriteLine("\t\tShadow Copy Dirs: {0}",     info.ShadowCopyDirectories); Console.WriteLine("\t\tShadow Copy Files: {0}",     info.ShadowCopyFiles);

Discussion

The Common Language Runtime is a very flexible and configurable environment, which is a good thing in most cases. But when debugging, it can be helpful to see the actual runtime settings that the program is dealing with, instead of trying to piece them together from multiple configuration files and policy settings. The appdomainSetup type provides a wealth of information about where the appdomain is storing things, what access it has been given, and where it is looking for assemblies. Debugging assembly-load problems can be frustrating at best, and having an extra arrow in your quiver to figure out what is happening will help with faster bug resolution.