2009-05-12 3 views
2

Я пытаюсь воссоздать существующую C Win32 DLL с помощью простой простой функции. Мне удалось это сделать с помощью VS C++ 2008 Express, и моя новая DLL работает на моей машине Vista dev и на компьютере клиента XP. Однако он не работает на других сайтах. Я проверил зависимости, а для моей DLL требуются файлы MSVCR90D.dll и KERNEL32.dll, где для исходной DLL требуется только KERNEL32.dll.Как создать Win32 DLL без MSVCR90D.dll?

Что такое MSVCR90D.dll и как создать простую DLL-версию Win32 без этой зависимости?

ответ

2

Ссылка со статической версией библиотеки времени выполнения C. Параметр находится в разделе «Генерация кода» в свойствах проекта. Тогда вам не придется беспокоиться о DLL MSVCR * вообще.

+0

Вам всегда нужно беспокоиться, если вы пишете плагин для приложения, так что вы не получите несовместимую реализацию malloc/free, например. В любом случае D означает Debug, и есть много причин никогда не развертывать сборку Debug. – RBerteig

+0

@RBerteig: В общем, вы правы в malloc/free и т. Д., Но в этом случае ProfK воссоздает существующую DLL, которая не имеет зависимости от DLL CRT. Он не собирается вводить проблемы, создавая свою новую DLL-работу одинаково. – RichieHindle

+2

Извините, перечитывая, похоже, что я, возможно, немного оторвался. Я часто видел совет, который давал просто ссылку на статику, когда реальной проблемой является сборка Debug, и это мое домашнее животное в наши дни. На самом деле это может нанести вред, если хостинг-приложение требует, чтобы зависимость действительно была в той же самой среде выполнения. Если мы предположим, что старая DLL действительно работает как построенная, то статическая связь действительно может быть правильным ответом. – RBerteig

8

D В конце MSVCR90D.dll показано, что вы скомпилировали ваш .exe в режиме отладки. Вы должны распространять свое приложение только в режиме выпуска.

Вы можете убедиться, что у них есть все, что им нужно, путем установки распространяемого пакета Microsoft Visual C++ 2008 x86 или x64. В противном случае вы можете просто скопировать нужные им файлы, найдя их на своем компьютере (сначала проверьте на% systemroot% \ system32)

См. this MSDN link.

+1

Я не могу дать +1 ответ, который рекомендует очищать библиотеки времени выполнения из папки system32 вашего компьютера. Не хорошая идея. Проблема в том, что механизм сбоку сбоку должен быть правильно обработан на целевой машине, а простая копия файла вряд ли будет правильной. – RBerteig

+1

@RBeteig: Что вы подразумеваете под «механизмом сборки бок о бок»? В чем проблема с размещением dll в папке, которая вам нужна для вашего приложения? Я не рекомендую копировать их в папку system32. –

0

Проверьте, установлен ли на вашей машине время выполнения 2008 года в его системе или нет. Если нет, вы можете установить его в своей системе или статически компилировать среду выполнения с вашим приложением.

3

«D» в названии означает отладку. Это явный индикатор сборки Debug Visual Studio. Используйте сборку Release, и все будет хорошо.

Если целевая система еще не имеет среды выполнения C, вы должны, как правило, использовать официальный установщик для ее установки. Некоторые из версий среды выполнения вы можете знать о таковы:

Вы можете также разработать полный пакет установки, который включает распространяемые библиотеки DLL (но никогда не - отладочная DLL), необходимая вашему приложению, и правильно обрабатывает сборки сборок (SxS) в кеш системной сборки, используя метод, известный как модули слияния. Этот подход проще, если у вас есть полная установка Visual Studio (а не бесплатная версия VS Express), но в результате установки пакетов по-прежнему могут вообще не работать с установкой среды выполнения на старых (например, Win 2K или 9x) платформах.

Статья Redistributing Visual C++ Files в MSDN описывает, что такое правила и как их соблюдать как можно проще. Это обеспечивает отправную точку, чтобы узнать больше о многих проблемах, связанных с развертыванием.

Если исходная DLL, функциональность которой вы заменяете, не имеет ссылки на MSVCR90.DLL, то она должна быть статически связана с временем выполнения. Вероятно, вы должны проверить предположения о предполагаемом приложении, которое будет вызывать вашу DLL. Смешивание библиотек времени выполнения C в одном процессе не всегда легко.Если хостинг-приложение уже использует MSVCR90.DLL, вам тоже нужно. Это большая проблема, чем подходит для ответа на конкретный вопрос, поэтому я бы посоветовал вам исследовать его и задавать новые вопросы по мере необходимости.

Другим способом избежать установки более поздних библиотек времени выполнения является ссылка на MSVCRT.DLL, которая распространяется в современных версиях окон в виде системного компонента. Это среда выполнения, поставляемая с Visual C 6.0, слегка обновляемая для критических проблем и поддерживающая ток в соответствии с ОС. Он вообще недоступен для 64-битных сборников, и довольно сложно обмануть Visual Studio, чтобы использовать его вместо более новой среды выполнения.

0

Вероятно, вы хотите создать версию вашей библиотеки DLL, протестировать ее и распространить, а не на сборку Debug, которую вы сейчас распространяете.

Однако можно создать отладочную DLL, которая зависит от MSVCR90.DLL, не отладочной версии этой DLL. Для этого (VS 2008 SP1, инструкции похожи для других VS):

  1. Перейти к Свойствам проекта (щелкните правой кнопкой мыши по проекту в панели Solution Explorer, выберите Свойства из меню).
  2. Перейдите в Свойства конфигурации \ C/C++ \ Генерация кода.
  3. В Runtime Library вы, вероятно, выбрали «Multi-threaded Debug DLL». Измените это на «Многопоточная DLL».

Вам придется перекомпилировать все, но теперь вы должны связываться с не-debug VS DLL.

Смежные вопросы