Я пытаюсь написать DLL смешанного режима, назовем ее «Клиент», чтобы заменить некоторые неуправляемые классы их управляемыми эквивалентами. На моем персональном компьютере все работает нормально, но когда я проверяю исходный код, наша сборочная машина не собирает проект. Он не распознает управляемые классы, которые я использую из другой библиотеки DLL, называемой «Core».
Я думаю, что проблема связана с предварительно скомпилированными заголовками. И вот почему:
Чтобы использовать классы из «Ядра», я добавил ссылку на проект «Ядро» в проекте «Клиент». Если я удалю эту ссылку, а затем соберу проект на моем персональном компьютере, он все равно будет работать. CLR PCH не перекомпилируется после удаления ссылки. Если я перекомпилирую CLR PCH, а затем скомпилирую проект, произойдет сбой с теми же ошибками, что и на компьютере сборки: управляемые классы не распознаются.
Мне кажется, что управляемые классы из DLL, которые вы импортируете, определены в предварительно скомпилированном заголовке. Я не смог проверить это, но это лучшее предположение, которое у меня есть. У кого-нибудь есть понимание, которое они могут пролить на этот вопрос? Разрешаются ли ссылки на проекты в смешанных DLL путем помещения хуков в управляемый PCH?
Шаги для воспроизведения
Следующее не имеет смысла для меня:
- Получить клиент для сборки.
- Удалить ссылку с клиента на ядро. Компилировать клиента. Клиент все еще строит. Этого не ожидается.
- Перекомпилируйте клиентский PCH, затем скомпилируйте клиент. Клиент компиляции не работает: классы в «Core» не определены. Это ожидаемое поведение.
- Добавить ссылку на ядро, скомпилировать. Компилировать клиента не удается по той же причине. Этого не ожидается
- Перекомпилируйте клиентский PCH, затем скомпилируйте клиент. Клиент компилируется нормально.
Мой вывод из этого эксперимента состоит в том, что ссылки вставляются в проект через предварительно скомпилированные заголовки и что что-то нарушается при работе, по крайней мере, на нашей сборочной машине.