Это скребок для головы. Вот сделка.
При развертывании бета-копии приложения ASP.NET, созданного с помощью Delphi 2007 для .NET, на тестовом сервере я столкнулся со странной проблемой. Приложению не удалось запуститься, потому что не удалось загрузить правильную версию поставщика данных ADO.NET, который я использовал.
Приложение будет запущено только при включении версии старой сборки в каталог bin. Однако я не хочу связываться с этим более старым поставщиком данных .NET, поэтому я полон решимости найти решение этой проблемы.
Первоначально я скомпилировал проект с использованием сборки поставщика данных .net, используемой как Copy Local, что должно было заставить Delphi использовать копию той версии сборки, которую я выбрал, когда добавил ее в папку «Ссылки» в Диспетчере проектов. , Фактическая сборка, которую я выбрал, была версией 9.10.2.0, и это версия сборки, которая отображается в каталоге bin вместе с приложением. Однако во время выполнения приложение пыталось привязаться к более ранней версии той же сборки, 9.0.2.7.
(На самом деле эта проблема возникает независимо от того, использую я версию GAC Copy Local или нет, поэтому я не думаю, что это проблема.)
При исследовании этой проблемы я создал новый проект и добавил ссылку на сборку 9.10.2.0. Тем не менее, обе утилиты настройки .NET 2.0 и Reflector показали, что приложение скомпилировано со ссылкой на сборку 9.0.2.7.
Проверка GAC Я увидел, что обе версии 9.0.2.7 и 9.10.2.0 были зарегистрированы. Попытка удалить версию 9.0.2.7 не удалась, поскольку эта версия поставщика все еще ссылалась на сборку в GAC.
Я зашел в реестр и вручную удалил все ссылки на провайдера 9.0.2.7. Затем я смог удалить его из GAC. Это ничего не изменило. Удаление сборки из существующего приложения и последующее добавление версии 9.10.2.0 обратно, а затем компиляция по-прежнему приводили к неверной информации о сборке, вставляемой в приложение. Как и раньше, создание нового приложения, которое ссылалось на сборку 9.10.2.0, не работало, так как ссылка на 9.0.2.7 все еще вставлялась в исполняемый файл.
Я проверил путь поиска в библиотеке Delphi. Я также полностью удалил все экземпляры старых файлов сборки с компьютера (в том числе из каталога временных файлов ASP.NET). У меня все еще есть проблема. Я попытался с помощью утилиты AppManifest Иссама Али вручную настроить манифест, но, очевидно, он не поддерживает приложения ASP.NET в Delphi 2007 для .NET.
Таким образом, GAC больше не содержит ссылок на 9.0.2.7, в реестре нет ссылок на него, нет путей к старому каталогу провайдера в диалогах проекта или параметров Delphi, старая сборка провайдера не включена файловая система и 9.0.2.7 не отображаются ни в одном из файлов проекта. Он также не отображается в файлах web.config, machine.config и других проверенных мной файлах. Тем не менее Delphi настаивает на использовании этой версии сборки всякий раз, когда я ссылаюсь на версию сборки 9.10.2.0. (Да, я перезапустил Delphi, а также перезапустил виртуальную машину, на которой выполнялась эта разработка.)
Даже после удаления поставщика данных 9.10.2.0 (старый уже был удален) и его повторной установки, добавление ссылки на поставщик данных в приложение приводит к тому, что приложение во время выполнения пытается загрузить старого поставщика (даже если нет ссылки на старый провайдер, видимо, остается в системе).
Я пробовал другие решения (которые стоит упомянуть здесь), но ни одно из них не сработало. Кто-нибудь видел это? Я собираюсь продолжить работу над этой проблемой, но я хотел бы услышать предложения. Я просто не могу заставить Delphi перестать вставлять старую информацию о сборке в проект.
За ухмылками я ввключая журнал ошибок от сбоя. Этот журнал по сути дублирует информацию, которую я получаю из журнала Fusion. Этот журнал взят из одного из простых приложений, которые я создал после удаления сборки 9.0.2.7 из GAC. Обратите внимание, что он ищет старую версию провайдера с самого начала.
Менеджер сборки загружен из: c: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ mscorwks.dll
Работает под исполняемым файлом c: \ windows \ microsoft.net \ framework \ v2.0.50727 \ aspnet_wp.exe
--- Подробный журнал ошибок следует.
=== Предварительная привязка информации о состоянии ===
LOG: Пользователь = TRAINING8A \ ASPNET
LOG: DisplayName = Advantage.Data.Provider, версия = 9.0.2.7, культура = нейтральная, PublicKeyToken = e33137c86a38dc06
(Полностью указано)
LOG: Appbase = file: /// C: / Inetpub / wwwroot / TestAdsVer2 /
LOG: Initial PrivatePath = C: \ Inetpub \ wwwroot \ TestAdsVer2 \ bin
Вызов сборки: TestAdsVer2, версия = 1.0.3572.17384, культура = нейтральная, PublicKeyToken = ноль.
LOG: эта привязка начинается в контексте загрузки по умолчанию.
LOG: Использование файла конфигурации приложения: C: \ Inetpub \ wwwroot \ TestAdsVer2 \ web.config
LOG: Использование файла конфигурации хоста: c: \ windows \ microsoft.net \ framework \ v2.0.50727 \ aspnet.config
LOG: Использование файла конфигурации компьютера из c: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ config \ machine.config.
LOG: ссылка после политики: Advantage.Data.Provider, версия = 9.0.2.7, культура = нейтральная, PublicKeyToken = e33137c86a38dc06
LOG: Попытка загрузки нового файла URL: /// c: /WINDOWS/Microsoft.NET/Framework/v2.0.50727/Tevent ASP.NET Files / testadsver2 / 07545aea / 3d068a5 / Advantage.Data.Provider.DLL.
LOG: Попытка загрузки нового файла URL: /// c: /WINDOWS/Microsoft.NET/Framework/v2.0.50727/Tevent ASP.NET Files / testadsver2 / 07545aea / 3d068a5 / Advantage.Data.Provider / Advantage.Data.Provider .DLL.
LOG: Попытка загрузки нового файла URL: /// C: /Inetpub/wwwroot/TestAdsVer2/bin/Advantage.Data.Provider.DLL.
WRN: сравнение имени сборки привело к несоответствию: Minor Version
ERR: не удалось завершить настройку сборки (hr = 0x80131040). Зондирование прекращено
Это продолжается так долго, что комментарии, которые я добавил к ответу LanceSC, больше не отображаются. Но я делаю то, что это интересный вопрос, к которому я хочу обратиться.
Вот мои последние два комментария к LanceSC
Установка, демонстрирующая это поведение, находится на виртуальной машине, которая больше не работает. Другой разработчик, которого я знаю, испытывал ту же проблему. Решением было отказаться от установки. Я чувствую, что что-то в установщике конкретной версии этого поставщика данных .NET оставило какой-то странный артефакт, который вызвал проблему. Это не происходит с любой другой сборкой этого поставщика данных. Я больше не ищу ответ на этот вопрос.
Говорили слишком рано. Мой коллега, сегодня (5 марта 2010 г.), столкнулся с той же ошибкой, с немного более ранней версией того же поставщика данных .NET (9.0.2.1). Сейчас он в том же положении, что и я. Он не может запустить свое приложение с какой-либо версией провайдера данных, кроме старой. Эта сборка использовалась как локальная копия, а старая версия отсутствует в gac. Используя его машину, мы запустили запуск MSBuild с опцией verbose. Сборка работала нормально, без ошибок. Тем не менее приложение компиляции не удалось запустить, так как не удалось найти старую версию поставщика.
Резюме
Мой коллега смирился с переустановкой Delphi 2007 (к счастью, он работал на виртуальной машине и имел вторую виртуальную машину с Delphi 2007, на которой провайдер данных .NET, который нарушал работу, никогда не устанавливался. Это тоже моя тактика.
На данный момент я пришел к выводу, что эта проблема не разрешима. Тем не менее, я оставляю этот вопрос открытым еще на неделю или около того. Если в ближайшие несколько недель не будет предложено приемлемое решение, я закрою этот вопрос.
Тем временем я попросил своего коллегу сохранить виртуальную машину у ненадлежащего поставщика, чтобы протестировать любое предлагаемое решение или исследование.