Я добавил интерфейс хостинга к собственному приложению C++, которое создает экземпляр CLR, создает пользовательский appDomainManager , и предоставляет вызовы для загрузки управляемых сборок в собственный процесс. В моей собственной функции C++ LoadDLL() я ожидал, что смогу протестировать входящую DLL для .net vs C++, вызвав LoadLibrary (dllPath), который, как я предполагал, вернет ошибку (NULL) для управляемых сборок, но я обнаружил, что это вместо этого возвращает дескриптор (это не работает в CLR, запущенном в неуправляемом процессе). Это обычное поведение для неуправляемого вызова LoadLibrary() на управляемой сборке?Что такое ожидаемое поведение LoadLibrary() при вызове из неуправляемого процесса (собственный C++) на управляемой сборке (C#)
Я не уверен, что я понимаю, как LoadLibrary может даже найти подходящую точку входа для проверки в управляемой сборке. Я знаю (один из возможных) способ решить проблему и способ, которым я планирую реализовать, просто использовать экземпляр CLR для доступа к API-интерфейсам отражения .net и проверить, управляется ли там там DLL ... но я «Я недоумеваю, что LoadLibrary() не возвращает неудачу, и я хотел бы понять, что мне здесь не хватает. Не определено ли поведение, должно ли оно всегда возвращать дескриптор или зависит от конфигурации управляемой сборки? Приветствуется любая ссылка на ссылки.
Редактировать:
Вопрос ответил на комментарии, закрыв.
.NET-сборка выглядит как обычная DLL для Windows. Так что LoadLibrary работает отлично. Это то, что вы обычно делаете дальше, вызывая GetProcAddress(), чтобы найти точку входа в DLL, которая не работает. Чистая управляемая сборка .NET не имеет. Поэтому не используйте LoadLibrary, это бессмысленно. Много и много [пример кода] (http://support.microsoft.com/kb/953836), чтобы показать вам, как использовать интерфейс _AppDomain. –
Спасибо за ответ. У меня уже есть интерфейс _AppDomain, реализованный и работающий, мне было просто интересно, почему LoadLibrary не терпит неудачу в сборке .net и хочет проверить нормальное поведение. Не кажется ли странным, что вызов преуспевает на собрании, на котором он не может фактически выполнять какие-либо полезные действия? Это просто фанковая логическая дыра или есть ли другое использование для загрузки управляемой сборки в неуправляемый процесс, о котором я не знаю? – NAW
Нет, это не странно. Сборка .NET также может содержать неуправляемый код, поэтому вызов LoadLibrary + GetProcAddress вполне подходит для такой сборки. В Windows нет специальной функции, запрещающей вызов LoadLibrary, когда DLL не имеет экспортированных функций. Например, DLL, которая просто содержит ресурсы, вполне допустима. –