.NET reflection question

Question

Hi,

The following code (packaged in a 'Console Application' Visual Studio project):

using System;
using System.Collections.Generic;
using System.Text;
using System.Reflection;

namespace TestReflection
{
    class Program
    {
        static void Main(string[] args)
        {
            bool found = false;
            foreach (Assembly assembly in AppDomain.CurrentDomain.GetAssemblies())
            {
                if (assembly.GetType("System.Diagnostics.Process") != null)
                {
                    found = true;
                    break;
                }
            }
            Console.WriteLine(found);
            Console.ReadKey();
        }
    }
}

prints 'True' when running it in debug mode (F5), but 'False' when launching it without the debugger (Ctrl-F5). Other classes show similar behavior (System.Text.RegularExpressions.Regex), others are found in both cases (System.IO.File).

I'm probably missing something obvious - why is this happenning?

(same thing happens in both Visual Studio 2005 and 2008).

UPDATE

List of assemblies found:

Debug mode:

mscorlib
TestReflection
System
Microsoft.VisualStudio.HostingProcess.Utilities
System.Windows.Forms

Run mode:

mscorlib
TestReflection

As the answers imply, in run mode the System assembly is missing (not loaded). My problem was that I was assuming GetAssemblies() was also returning not loaded assemblies.

While this explains the behavior for System.Diagnostics.Process, why is my code finding System.IO.File in both run and debug modes?

Thanks!

UPDATE 2

I've changed the code to loop through the loaded assemblies and the current assembly, collecting a list of assemblies referenced by these. If after iterating the loaded assemblies I can't find the type I'm looking for, I start loading and inspecting the referenced assemblies.

It seems that even if I have a reference to System.dll in my project (I'm looking at the properties of the 'System' reference in Visual Studio), my executable file only references mscorlib.dll (according to Reflector).

How do I add a 'real' reference to System.dll? Placing a dummy line

new System.Diagnostics.ProcessStartInfo();

at the start of Main does the trick (things work as expected, Reflector shows references for both mscorlib.dll and System.dll when inspecting the executable), but it is a hack.

Thanks again!

Answer 1

I imagine that some assemblies are not directly referenced by your project, but when debugged are being mapped into your process BY the debugger itself.

Make sure the assemblies you are looking for are in the References for you project.

Answer 2

The debugger in VS does its best to trick and fool you into thinking that you're running your application as it would on a production machine. However, it is doing a whole bunch of stuff that you wouldn't expect, such as eagerly loading assemblies, keeping vars alive long after they would have normally been collected, etc.

In a release build, the CLR will not load an assembly into the appdomain until a type or an instance of a type is needed to execute code. This behavior is not guaranteed at debug time.

If your code is sensitive to these changes, I'd suggest redesigning it or checking System.Diagnostics.Debugger.IsAttached.

Answer 3

AppDomain.GetAssemblies does not return all assemblies that you have referenced, rather it returns all assemblies that are currently loaded into the appdomain.

Clearly, the Diagnostics.Process class is not directly used by your application and will thus not be loaded when running outside the debugger.

So why do we find System.IO.File but not System.Diagnostics.Process? The reason is that the two classes, though they reside in the same top-level namespace System, actually lives in two different assemblies. This is easily seen if you look up the two classes in the Visual Studio Object Browser. The File class happens to live in the mscorlib dll while the Process class lives in the System dll.

Since no .Net application can run without mscorlib that assembly will be loaded, while System.dll is not loaded since you are not referencing any types that lives in that dll.

Answer 4

Usually the assemblies are not being loaded until needed. When running in debug mode, the debugger loads the Microsoft.VisualStudio.HostingProcess.Utilities assembly at startup. My guess is that this assembly calls into the System assembly and hence System is loaded at startup in debug mode.

Answer 5

You might find it interesting to try this line with and without a debugger attached:

Console.WriteLine(Process.GetCurrentProcess().ProcessName);

In short, as @Will notes, when you run from within VS with a debugger attached, you're not actually running 'your exe' at all, but rather a whole framework that the VS debugger sets up for you. Things are going to be different.