Which reflection operations will tolerate a missing DLL?

Suppose we have A.dll:

namespace A
{
    public class A1
    {
    }
}

and B.dll:

namespace B
{
    using System.Collections.Generic;
    using A;

    public class B1
    {
        public A1 Prop { get; set; }

        public IList<A1> Fun(A1 val)
        {
            return new A1[1] { val };
        }

        public static class Inner
        {
            public static readonly int X = 69;

            public static int Y { get { return 42; } }
        }
    }
}

and C.exe:

namespace C
{
    using System;
    using System.Reflection;
    using System.Diagnostics;

    internal static class Program
    {
        private static void Main()
        {
            Assembly b = Assembly.Load("B");
            Type[] types = b.GetExportedTypes();
            Type b1 = b.GetType("B.B1");
            Type inner = b.GetType("B.B1+Inner");
            Debug.Assert(b1 == inner.DeclaringType);
            FieldInfo[] fields = inner.GetFields(BindingFlags.Static | BindingFlags.Public);
            Debug.Assert(fields.Length == 1);
            fields[0].GetValue(null);
            PropertyInfo[] properties = inner.GetProperties(BindingFlags.Static | BindingFlags.Public);
            Debug.Assert(properties.Length == 1);
            properties[0].GetValue(null, null);
        }
    }
}

Then, we install B.dll and C.exe, but we do not install A.dll. Does the .NET Framework CLR promise that the operations in C.Program.Main will succeed even though A.dll is not found at run time? With .NET Framework 4.5.2 on Windows 7 SP1, these operations do succeed, but I have not found any documentation that promises they will work in future versions of the CLR as well.

If I change A.A1 to a value type, then b.GetExportedTypes() throws, presumably because the CLR cannot compute the memory layout of B.B1—even though the program did not attempt to create an instance of B.B1. If documentation exists on this topic, I hope it goes to this kind of detail.