.net — Каково ожидаемое поведение LoadLibrary () при вызове из неуправляемого процесса (нативный C ++) в управляемой сборке (C #)

Я добавил хост-интерфейс в собственное приложение C ++, которое создает экземпляр CLR, создает собственный appDomainManager и предоставляет вызовы для загрузки управляемых сборок в собственный процесс. В моей родной функции C ++ LoadDLL () я ожидал, что смогу проверить входящую dll для .net против C ++, вызвав LoadLibrary (dllPath), который, как я предполагал, вернет ошибку (NULL) для управляемых сборок, но я обнаружил, что она вместо этого возвращает дескриптор (в настоящее время CLR не выполняется в неуправляемом процессе). Это нормальное поведение для неуправляемого вызова LoadLibrary () в управляемой сборке?

Я не уверен, что понимаю, как LoadLibrary может даже найти подходящую точку входа для тестирования в управляемой сборке. Я знаю (один из возможных) способ решения проблемы, и способ, которым я планирую реализовать, состоит в простом использовании экземпляра CLR для доступа к API-интерфейсам отражения .net и проверки, управляется ли там сначала DLL … но я Я озадачен тем фактом, что LoadLibrary () не возвращает ошибку, и я хотел бы понять, что мне здесь не хватает. Поведение не определено, должно ли оно всегда возвращать дескриптор, или оно зависит от конфигурации управляемой сборки? Любая ссылка на ссылки приветствуется.

Редактировать:

Вопрос ответил в комментариях, закрытие.