Это головорез. Вот сделка.
При развертывании бета-копии приложения ASP.NET, созданного с помощью Delphi 2007 для .NET, на тестовом сервере я столкнулся со странной проблемой. Приложению не удалось запустить, потому что оно не могло загрузить правильную версию поставщика данных ADO.NET, который я использовал.
Приложение запускалось только при включении версии старой сборки в каталог bin. Однако я не хочу быть привязанным к этому более старому поставщику данных .NET, поэтому я полон решимости найти решение этой проблемы.
Первоначально я скомпилировал проект со сборкой поставщика данных .net, используемой как Copy Local, что должно было заставить Delphi использовать копию той версии сборки, которую я выбрал, когда добавил ее в папку References в диспетчере проектов. Фактически я выбрал сборку версии 9.10.2.0, и это версия сборки, которая отображается в каталоге bin вместе с приложением. Однако во время выполнения приложение пыталось выполнить привязку к более ранней версии той же сборки, 9.0.2.7.
(На самом деле эта проблема возникает независимо от того, использую ли я версию Copy Local для GAC, поэтому я не думаю, что это проблема.)
Исследуя эту проблему, я создал новый проект и добавил ссылку на сборку 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 перестать вставлять старую информацию о сборке в проект.
Для ухмылки я включаю журнал ошибок из-за сбоя. Этот журнал по сути дублирует информацию, которую я получаю из журнала слияния. Этот журнал взят из одного из простых приложений, которые я создал после удаления сборки 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 --- Подробная ошибка журнал следует.
=== Информация о состоянии предварительной привязки === ЖУРНАЛ: Пользователь = TRAINING8A \ ЖУРНАЛ ASPNET: DisplayName = Advantage.Data.Provider, версия = 9.0.2.7, культура = нейтральный, PublicKeyToken = e33137c86a38dc06 (полностью задано) LOG: Appbase = файл: /// C: / Inetpub / wwwroot / TestAdsVer2 / LOG: Initial PrivatePath = C: \ Inetpub \ wwwroot \ TestAdsVer2 \ bin
Вызывающая сборка: TestAdsVer2, версия = 1.0.3572.17384, культура = нейтральная, PublicKeyToken = null.
ЖУРНАЛ: Эта привязка начинается в контексте загрузки по умолчанию. ЖУРНАЛ: использование файла конфигурации приложения: C: \ Inetpub \ wwwroot \ TestAdsVer2 \ web.config ЖУРНАЛ: использование файла конфигурации хоста: c: \ windows \ microsoft.net \ framework \ v2.0.50727 \ aspnet.config ЖУРНАЛ: использование файла конфигурации компьютера из c: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ config \ machine.config. ЖУРНАЛ: ссылка на пост-политику: Advantage.Data.Provider, Version = 9.0.2.7, Culture = нейтральный, PublicKeyToken = e33137c86a38dc06 LOG: Попытка загрузки нового файла URL: /// c: /WINDOWS/Microsoft.NET/Framework/v2 .0.50727 / Временные файлы ASP.NET / testadsver2 / 07545aea / 3d068a5 / Advantage.Data.Provider.DLL. ЖУРНАЛ: попытка загрузки нового файла URL: /// c: /WINDOWS/Microsoft.NET/Framework/v2.0.50727/Temporary ASP.NET Files / testadsver2 / 07545aea / 3d068a5 / Advantage.Data.Provider / Advantage.Data.Provider .DLL. ЖУРНАЛ: попытка загрузки нового файла 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 с опцией подробного описания. Сборка прошла нормально, без ошибок. Тем не менее, приложение компиляции не запустилось, так как не смогло найти старую версию провайдера.
Резюме
Мой коллега смирился с переустановкой Delphi 2007 (к счастью, он работал с виртуальной машиной, и у него была вторая виртуальная машина с Delphi 2007, в которой не был установлен провайдер данных .NET). Это тоже была моя тактика.
На данный момент я пришел к выводу, что эта проблема неразрешима. Тем не менее, я оставляю этот вопрос открытым еще на неделю или около того. Если в ближайшие несколько недель не будет предложено никакого реального решения, я закрою этот вопрос.
Тем временем я попросил своего коллегу сохранить виртуальную машину у некорректно работающего провайдера, чтобы протестировать любое предлагаемое решение или расследование.
