Short answer: yes, PEVerify requires loading reference assemblers.
The build format is pretty self-contained. But there really are a few things that PEVerify should check for in the assembly references.
Shared instances
In an assembly, when you use a generic type or generic method, the original generic attribute is not preserved, and you need to load the definition of the type or method to validate the instance correctly, as for arity (does the instance have its own number of common arguments?) And for constraints (generic argument satisfies the general constraint specified in the general parameter?). Verification will fail if PEVerify cannot find the referenced assemblies.
Availability of reference elements
If you call a method or control a field defined in another assembly, PEVerify will attempt to load the assembly defining the member to verify that the element has the appropriate visibility.
He will not be able to check if he cannot find the assembly with the error "Unable to resolve token."
There are several other cases when you need to correctly read a piece of metadata that needs to resolve the type reference, and thus load the assembly containing it, but I don't think PEVerify checks them:
Creating an instance of Custom Attribute containing enumerations:
For instance:
[AttributeUsage (AttributeTargets.Field)]
You need to load the attribute definition in order to know that it supports int32, spanning more than 4 bytes in sequential form of user attributes.
Fields whose values are serialized in binary form:
Some compilers may decide to keep a constant value in binary form in the assembly. In the case when the type of a constant is not a well-known primitive, you need to allow a reference to this type to find out its size.
But then again, I don't think PEVerify is checking these cases. I am really sure that it does not check the encoding of user attributes, for the second element I am not sure.