ASP.NET с Delphi 2007 за .NET. Неуспешно зареждане на файл или сглобка... Дефиницията на манифеста на локализираната сглобка не съответства на препратката на сглобката

Това е главоболие. Ето я сделката.

Докато внедрявах бета копие на ASP.NET приложение, изградено с Delphi 2007 за .NET, на тестов сървър, срещнах странен проблем. Приложението не можа да се стартира, защото не можа да зареди правилната версия на ADO.NET доставчик на данни, който използвах.

Само чрез включване на версия на старата сглобка в директорията bin приложението ще стартира. Въпреки това не искам да бъда обвързан с този по-стар .NET доставчик на данни, така че съм решен да намеря решение на този проблем.

Първоначално компилирах проекта със сглобката на .net доставчик на данни, използвана като Copy Local, което трябваше да накара Delphi да използва копие на тази версия на сглобката, която избрах, когато я добавих към папката References в Project Manager. Действителното сглобяване, което избрах, беше версия 9.10.2.0 и това е версията на сглобката, която се появява в директорията bin, заедно с приложението. Въпреки това, по време на изпълнение приложението се опитваше да се свърже с по-ранна версия на същия сбор, 9.0.2.7.

(Всъщност този проблем възниква независимо дали използвам GAC версията на Copy Local, така че не мисля, че това е проблемът.)

Докато проучвах този проблем, създадох нов проект и добавих препратка към сборката 9.10.2.0. И все пак, както .NET 2.0 Configuration Utility, така и 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 на Issam Ali, за да коригирам ръчно манифеста, но очевидно тя не поддържа 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, Version=9.0.2.7, Culture=neutral, PublicKeyToken=e33137c86a38dc06 (Напълно посочен) РЕГИСТРАТОР: Appbase = file:///C:/Inetpub/wwwroot/TestAdsVer2/ LOG: Първоначален 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. РЕГИСТРАТОР: Справка след прилагане на правилата: Advantage.Data.Provider, Version=9.0.2.7, Culture=neutral, PublicKeyToken=e33137c86a38dc06 РЕГИСТРАТОР: Опит за изтегляне на нов 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/Временни ASP.NET файлове/testadsver2/07545aea/3d068a5/Advantage.Data.Provider/Advantage.Data.Provider .DLL. Дневник: Опит за изтегляне на нов URL файл:///C:/Inetpub/wwwroot/TestAdsVer2/bin/Advantage.Data.Provider.DLL. WRN: Сравняването на името на асемблирането доведе до несъответствие: Допълнителна грешка на версията: Неуспешно завършване на настройката на асемблирането (hr = 0x80131040). Проучването е прекратено

Това продължи толкова дълго, че коментарите, които добавих към отговора на LanceSC, вече не се показват. Но смятам, че това е интересен въпрос, който искам да разгледам.

Ето последните ми два коментара към LanceSC

  1. Инсталацията, която показа това поведение, е във виртуална машина, която вече не функционира. Друг разработчик, когото познавам, имаше същия проблем. Решението беше да изоставя инсталацията. Чувствам, че нещо в инсталатора на конкретната версия на този .NET доставчик на данни е оставило някакъв странен артефакт, който е причинил проблема. Това не се случва с друга компилация на този доставчик на данни. Вече не търся отговор на този въпрос.

  2. Говори твърде рано. Един мой колега днес (5 март 2010 г.) се натъкна на същата грешка с малко по-ранна версия на същия този .NET доставчик на данни (9.0.2.1). Сега той е в същото положение, в което бях аз. Той не може да стартира приложението си с никоя версия на доставчика на данни, освен старата. Това сглобяване се използваше като локално копие и старата версия не е в gac. Използвайки неговата машина, стартирахме MSBuild с опцията verbose. Компилацията работи добре без грешки. Независимо от това приложението за компилиране не успя да се стартира, тъй като не успя да намери старата версия на доставчика.

Резюме

Моят колега се примири с преинсталирането на Delphi 2007 (за щастие, той работеше във виртуална машина и имаше втора виртуална машина с Delphi 2007, в която проблемният доставчик на данни .NET никога не беше инсталиран. Това беше и моята тактика.

На този етап стигнах до извода, че този проблем не е разрешим. Въпреки това оставям този въпрос отворен за още около седмица. Ако през следващите няколко седмици не бъде предложено осъществимо решение, ще затворя този въпрос.

Междувременно помолих моя колега да запази виртуалната машина с неправилно работещия доставчик, за да тества всяко предложено решение или разследване.


person Cary Jensen    schedule 12.10.2009    source източник
comment
Ето още едно парче от пъзела, но то не е окончателно по никакъв начин. Създадох чиста инсталация на операционната система и RAD Studio 2007. Инсталирах версията 9.10.2.0 на доставчика на данни (никога не съм инсталирал версията 9.0.2.7). След това извлякох целия проект от контрола на източника. Тази версия работи добре и не изисква версия 9.0.2.7 на доставчика. С други думи, не изглежда, че заявката за по-стария доставчик е по някакъв начин вградена в изходните файлове на проекта.   -  person Cary Jensen    schedule 22.11.2009


Отговори (3)


Delphi 2007 използва MSBuild за извършване на действителните компилации; обаче кодът в техния продукт, който синхронизира промените между IDE и MSBuild, е много крехък. Подозрението ми е, че компилационните файлове не са синхронизирани с IDE. Лесен начин да ги актуализирате е както следва:

Отворете вашия редактор на системния регистър, отидете на

HKEY_LOCAL_MACHINE\SOFTWARE\Borland\BDS\5.0\Globals

Променете стойността на ForceEnvOptionsUpdate на 1.

Отворете RAD Studio IDE.

За да потвърдите подозрението ми, трябва да намерите файловете, които Delphi.NET предава на MSBuild. Те се намират някъде под профила на текущия потребител. Може също да искате да разгледате опциите в помощта на Delphi, за да го накарате да направи подробен MSBuild изход.

person LanceSc    schedule 16.11.2009
comment
Благодаря ви за предложението. Ще погледна и ще докладвам какво открих. - person Cary Jensen; 19.11.2009
comment
Погледнах регистъра и открих, че ключът ForceEnvOptionsUpdate липсва. Добавих този ключ със стойността на низ 1 (2007 readme.txt споменава, че това е стойност на низ). Това все още нямаше ефект. Предполагам, че MSBuild използва dproj файла. Не видях никаква препратка там, която би трябвало да окаже влияние. Също така претърсих всички файлове в директорията на .NET framework, директорията на проекта и директориите на RAD Studio 5.0 и директориите на документи и настройки за 9.0.2.7 без успех. Включих скрити и системни файлове в това търсене. Все още се чеша по главата. - person Cary Jensen; 21.11.2009
comment
Дотогава претърсих целия твърд диск за 9.0.2.7. Търсенето намери съвпадения. Всички те бяха или свързани с кеширани съобщения за грешка или с дневници на синтез (като този, който показах в първоначалния въпрос), както и резервно копие на системния регистър, което направих, преди да премахна всички останали остатъци от доставчика 9.0.2.7. - person Cary Jensen; 22.11.2009
comment
Изглежда, че ще трябва да опитате и да отстраните грешки в задачата MSBuild, която се случва във фонов режим. Най-лесният начин да направите това, отворете командния ред на RAD Studio, навигирайте до папката с вашия проект и изпълнете следната команда msbuild /verboisty:diagnostic › log.out След това ще трябва да прегледате log.out, за да видите къде се намира събранието от. - person LanceSc; 23.11.2009
comment
Благодаря за това предложение. В момента съм дълбоко в различен проект и ще направя това, когато изляза на въздух. Между другото, мога да копирам всички файлове на проекта в друга виртуална машина, която никога не е имала инсталиран файл 9.0.2.7, и всичко работи добре. Така че изглежда, че това не е въпрос на нещо, което витае във файловете на проекта. - person Cary Jensen; 05.12.2009
comment
Инсталацията, която показа това поведение, е във виртуална машина, която вече не функционира. Друг разработчик, когото познавам, имаше същия проблем. Решението беше да изоставя инсталацията. Чувствам, че нещо в инсталатора на конкретната версия на този .NET доставчик на данни е оставило някакъв странен артефакт, който е причинил проблема. Това не се случва с друга компилация на този доставчик на данни. Вече не търся отговор на този въпрос. - person Cary Jensen; 02.03.2010
comment
Говори твърде рано. Един мой колега днес се натъкна на същата грешка с малко по-ранна версия на същия този доставчик на данни .NET (9.0.2.1). Сега той е в същото положение, в което бях аз. Той не може да стартира приложението си с никоя версия на доставчика на данни, освен старата. Това сглобяване се използваше като локално копие и старата версия не е в gac. Използвайки неговата машина, стартирахме MSBuild с опцията verbose. Компилацията работи добре без грешки. Независимо от това приложението за компилиране не успя да се стартира, тъй като не успя да намери старата версия на доставчика. - person Cary Jensen; 05.03.2010

Опитахте ли да направите grep в директориите на Delphi и .NET framework за 9.0.2.7, за да видите дали е някъде в конфигурационен файл?

Нещо като:

grep -d 9\.0\.2\.7 *.xml

Други места, които можете да търсите:

  • потърсете във файловете на проекта за 9.0.2.7
  • търсене в регистъра за 9.0.2.7 и търсене с помощта на публичния токен
  • Ако това приложение използва BDP, можете също да търсите в конфигурационните файлове на BDP
person Jeremy Mullin    schedule 12.10.2009
comment
Претърсих всичко, за което се сетя. Не мога да намеря 9.0.2.7 никъде (поне вече). - person Cary Jensen; 12.10.2009
comment
Погледнахте ли във файла project.dproj? Създадох приложение delphi за .net asp.net и намерих посочената информация за сглобяване в моя файл project.dproj. - person Jeremy Mullin; 12.10.2009
comment
Да направих го. Единствените препратки там сочат към директорията, където се намира версията 9.10.2.0 на сборката. (Асамблеята на версията 9.0.2.7, когато беше инсталирана, се появи в папка, различна от версията 9.10.2.0.) - person Cary Jensen; 12.10.2009

Сблъсках се с нещо много подобно и това ме изправи абсолютно на стената за дни. Имах препратка към Oracle.DataAccess.dll, която беше решително заседнала, сочеща към стара версия, независимо от това, което беше в GAC, в пътя за търсене и т.н. Никакво рестартиране на модификации на .dproj файловете никога нямаше да работи.

Това, което в крайна сметка открих, беше, че обидното парче, което се държеше за старата препратка, беше генерираният Oracle.DataAccess.dcpil в директорията C:\Users\Public\documents\rad studio\5.0\dcp.

Беше на повече от година - какъвто и да беше случаят, Delphi не искаше да пише върху него.

След като го изтрих, Delphi весело създаде друг и разбира се, сега той сочи към сборката, която искам.

Уф, разочароващо!

person Ritchie annand    schedule 26.03.2011
comment
Хммм. Това е интересно предложение. Почти съм сигурен, че изтрих почти всичко и всичко, което не ми трябваше, и съм почти сигурен, че изтрих всички dcpil файлове, дори тези в публичните папки. Не съм разглеждал тази виртуална машина повече от година и не съм виждал този проблем извън една конкретна версия на Advantage .NET Data Provider. Предполагам, че проблемът се дължи на нещо необичайно с тази конкретна версия на драйвера. - person Cary Jensen; 27.03.2011
comment
Това може да бъде много добре. Всъщност попаднах на вашата публикация тук в началото на процеса на опит да разбера собствения си проблем. Ефектите бяха много сходни: без значение какво правех, искаше по-стара версия на библиотека. Спомням си, че си помислих, Господи - ако Кари Дженсън не може да разбере този проблем, прецакан съм. Така или иначе, да се надяваме, че ако някой е прецакан от грешния файл в директорията Dcp, той ще го намери, използвайки същите думи за търсене, които използвах, за да стигна до тук :) - person Ritchie annand; 29.04.2011