ASP.NET 与 Delphi 2007 for .NET。无法加载文件或程序集…找到的程序集的清单定义与程序集引用不匹配
这是一个令人头疼的问题。事情是这样的。
在将使用 Delphi 2007 for .NET 构建的 ASP.NET 应用程序的测试版副本部署到测试服务器时，我遇到了一个奇怪的问题。应用程序无法启动，因为它无法加载我正在使用的 ADO.NET 数据提供程序的正确版本。
只有在 bin 目录中包含旧程序集的版本，应用程序才会运行。然而，我不想被这个旧的.NET 数据提供者束缚，所以我决心找到解决这个问题的方法。
我最初使用 .net 数据提供程序集作为“复制本地”来编译该项目，这应该导致 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 临时文件目录中）。我仍然遇到问题。我尝试使用 Issam Ali 的 AppManifest 实用程序手动调整清单，但显然它不支持 Delphi 2007 for .NET 中的 ASP.NET 应用程序。
因此，GAC 不再包含对 9.0.2.7 的引用，注册表中没有对它的引用，项目或 Delphi 选项对话框中没有旧提供程序目录的路径，旧提供程序程序集不在文件系统上，并且 9.0.2.7 未出现在任何项目文件中。它也没有出现在 web.config、machine.config 或我检查的任何其他文件中。尽管如此，只要我引用 9.10.2.0 版本的程序集，Delphi 就坚持使用该版本的程序集。 （是的，我重新启动了 Delphi，并且还重新启动了正在执行此开发的虚拟机。）
即使在卸载 9.10.2.0 数据提供程序（旧版本已卸载）并重新安装它之后，将数据提供程序引用添加到应用程序会导致运行时应用程序尝试加载旧提供程序（即使系统中显然没有保留对旧提供程序的引用）。
我尝试过其他解决方案（这里值得一提），但没有一个有效。有人看过这个吗？我将继续解决这个问题，但我很想听到建议。我只是无法让 Delphi 停止将旧的程序集信息插入到项目中。
为了微笑，我包括了失败的错误日志。该日志本质上重复了我从融合日志中获得的信息。此日志来自我从 GAC 中删除 9.0.2.7 程序集后创建的简单应用程序之一。请注意，它从一开始就在寻找旧版本的提供程序。
程序集管理器加载自：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 （详细说明） 日志：Appbase = file:///C:/Inetpub/wwwroot/TestAdsVer2/ 日志：初始 PrivatePath = C:\Inetpub\wwwroot\TestAdsVer2\bin
调用程序集：TestAdsVer2，版本=1.0.3572.17384，Culture=neutral，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=neutral、PublicKeyToken=e33137c86a38dc06 日志：尝试下载新的 URL 文件:///c:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/Temporary ASP.NET Files/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：比较程序集名称导致不匹配：次要版本 错误：无法完成程序集设置（hr = 0x80131040）。探测终止
这已经持续了很长时间，以至于我添加到 LanceSC 答案中的评论不再显示。但我确实认为这是我想要解决的一个有趣的问题。
这是我对 LanceSC 的最后两条评论
表现出此行为的安装位于不再运行的虚拟机中。我认识的另一位开发人员也遇到了同样的问题。解决办法是放弃安装。我觉得这个 .NET 数据提供程序的特定版本的安装程序中的某些内容留下了一些奇怪的工件，从而产生了问题。此数据提供程序的任何其他版本都不会发生这种情况。我不再寻求这个问题的答案。
说得太早了。今天（2010 年 3 月 5 日），我的一位同事在使用同一个 .NET 数据提供程序的稍早版本 (9.0.2.1) 时遇到了同样的错误。他现在的处境和我一样。他无法使用任何版本的数据提供程序运行他的应用程序（除了旧版本）。该程序集被用作本地副本，旧版本不在 gac 中。使用他的机器，我们使用详细选项运行 MSBuild。构建工作正常，没有错误。尽管如此，编译应用程序未能运行，因为未能找到旧版本的提供程序。
总结
我的同事无奈地重新安装了 Delphi 2007（幸运的是，他正在一台 VM 中工作，并且还有第二台装有 Delphi 2007 的 VM，其中从未安装过有问题的 .NET 数据提供程序。这也是我的策略。
此时， 的结论是这个问题无法解决，但是，我将这个问题再留一个星期左右，如果在接下来的几周内没有提出可行的解决方案，我将关闭这个问题。
我 同事将虚拟机保留在行为不当的提供商处，以便测试所提出的任何解决方案或调查。
This one’s a head scratcher. Here’s the deal.
While deploying a beta copy of an ASP.NET application built with Delphi 2007 for .NET to a test server I encountered an odd problem. The application was unable to start because it could not load the correct version of an ADO.NET data provider that I was using.
Only by including a version of the old assembly in the bin directory would the application run. However, I don’t want to be tied to this older .NET data provider, so I am determined to find a solution to this problem.
I originally compiled the project with the .net data provider assembly used as Copy Local, which should have caused Delphi to use a copy of that version of the assembly that I selected when I added it to the References folder in the Project Manager. The actual assembly that I selected was version 9.10.2.0, and that is the version of the assembly that appears in the bin directory, along with the application. However, at runtime the application was trying to bind to an earlier version of the same assembly, 9.0.2.7.
(Actually, this problem occurs whether or not I use the GAC version of Copy Local, so I don’t think this is the issue.)
While investigating this problem I created a new project, and added a reference to the 9.10.2.0 assembly. Still, both the .NET 2.0 Configuration Utility and Reflector showed that the application compiled with a reference to the 9.0.2.7 assembly.
Inspecting the GAC I saw that both 9.0.2.7 and 9.10.2.0 versions were registered. Attempting to remove the 9.0.2.7 version fails, since that version of the provider was still referencing the assembly in the GAC.
I went into the registry and manually removed all references to the 9.0.2.7 provider. I then was able to delete it from the GAC. This didn’t change anything. Removing the assembly from an existing application and then adding the 9.10.2.0 version back, then compiling, still resulted in the wrong assembly information being inserted into the application. As before, creating a new application that referenced the 9.10.2.0 assembly didn’t work, as a reference to 9.0.2.7 was still being inserted into the executable.
I’ve checked the Delphi library search path. I also removed every instance of the old assembly files from the machine altogether (including from the ASP.NET Temporary Files directory). I still got the problem. I tried using Issam Ali’s AppManifest utility to manually adjust the manifest, but apparently it does not support ASP.NET applications in Delphi 2007 for .NET.
So, the GAC no longer contains references to 9.0.2.7, there are no references to it in the registry, there are no paths to the old provider directory in the project or Delphi options dialogs, the old provider assembly is not on the file system, and 9.0.2.7 does not appear in any of the project files. Nor does it appear in web.config, machine.config, or any other file I checked. Nonetheless, Delphi insists on using this version of the assembly anytime I reference the 9.10.2.0 version of the assembly. (Yes, I restarted Delphi, and also restarted the Virtual Machine in which this development was being performed.)
Even after uninstalling the 9.10.2.0 data provider (the older one was already uninstalled), and reinstalling it, adding the data provider reference to an application results in the runtime application attempting to load the old provider (even though no reference to the old provider apparently remains in the system).
I’ve tried other solutions (which are worth mentioning here), but none worked. Anybody seen this? I am going to continue working on this problem, but I’d love to hear suggestions. I just can’t get Delphi to stop inserting the old assembly information into the project.
For grins I’m including the error log from the failure. This log essentially duplicates the information I get from the fusion log. This log is from one of the simple apps I created after removing the 9.0.2.7 assembly from the GAC. Notice that it’s looking for the old version of the provider from the outset.
Assembly manager loaded from: c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Running under executable c:\windows\microsoft.net\framework\v2.0.50727\aspnet_wp.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: User = TRAINING8A\ASPNET
LOG: DisplayName = Advantage.Data.Provider, Version=9.0.2.7, Culture=neutral, PublicKeyToken=e33137c86a38dc06
(Fully-specified)
LOG: Appbase = file:///C:/Inetpub/wwwroot/TestAdsVer2/
LOG: Initial PrivatePath = C:\Inetpub\wwwroot\TestAdsVer2\bin
Calling assembly : TestAdsVer2, Version=1.0.3572.17384, Culture=neutral, PublicKeyToken=null.
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Inetpub\wwwroot\TestAdsVer2\web.config
LOG: Using host configuration file: c:\windows\microsoft.net\framework\v2.0.50727\aspnet.config
LOG: Using machine configuration file from c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Post-policy reference: Advantage.Data.Provider, Version=9.0.2.7, Culture=neutral, PublicKeyToken=e33137c86a38dc06
LOG: Attempting download of new URL file:///c:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/Temporary ASP.NET Files/testadsver2/07545aea/3d068a5/Advantage.Data.Provider.DLL.
LOG: Attempting download of new URL file:///c:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/Temporary ASP.NET Files/testadsver2/07545aea/3d068a5/Advantage.Data.Provider/Advantage.Data.Provider.DLL.
LOG: Attempting download of new URL file:///C:/Inetpub/wwwroot/TestAdsVer2/bin/Advantage.Data.Provider.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Minor Version
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated
This has gone on so long that the comments that I added to LanceSC's answer are no longer showing. But I do thing this is an interesting item that I want to address.
Here's my last two comments to LanceSC
The installation that exhibited this behavior is in a VM that is no longer functioning. Another developer I know experienced this same problem. The solution was to abandon the installation. I feel that something in the installer of the particular version of this .NET data provider left some strange artifact that produced the problem. It does not happen with any other build of this data provider. I am no longer pursuing an answer to this question.
Spoke too soon. A colleague of mine, today (March 5, 2010), encountered this same error, with a slightly earlier version of this same .NET data provider (9.0.2.1). He is now in the same position I was. He cannot run his application with any version of the data provider, save the old one. That assembly was being used as a local copy, and the old version is not in the gac. Using his machine, we ran the run MSBuild with the verbose option. The build worked fine with no errors. Nonetheless, the compile application failed to run, having failed to find the old version of the provider.
Summary
My colleague resigned himself to reinstalling Delphi 2007 (fortunately, he was working in a VM, and had a second VM with Delphi 2007 in which the offending .NET data provider had never been installed. This was also my tactic.
At this point, I have concluded that this problem is not solvable. Nonetheless, I am leaving this question open for another week or so. If no feasible solution is proposed in the next few weeks, I will close this question.
In the meantime, I have asked my colleague to preserve the VM with the misbehaving provider, in order to test any solution or investigation that is proposed.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（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 输出。
Delphi 2007 uses MSBuild to perform the actual builds; however, the code in their product that syncs changes between the IDE and MSBuild is very brittle. My suspicion is that the build files are out of sync with the IDE. An easy way to update them is as follow:
Open your registry editor go to
HKEY_LOCAL_MACHINE\SOFTWARE\Borland\BDS\5.0\Globals
Change the value of ForceEnvOptionsUpdate to 1.
Open the RAD Studio IDE.
In order to confirm my suspicion you need to locate the files that Delphi.NET feeds to MSBuild. They are located somewhere under the current user's profile. You may also want to look at options in the Delphi help to have it do a verbose MSBuild output.
您是否尝试过 grep 9.0.2.7 的 Delphi 和 .NET Framework 目录以查看它是否位于某个配置文件中？
类似于：
您可能搜索的其他地方：
Have you tried grep'ing the Delphi and .NET framework directories for 9.0.2.7 to see if it is in a config file somewhere?
Something like:
Other places you might search:
我遇到了非常类似的事情，这让我好几天都陷入困境。我有一个对 Oracle.DataAccess.dll 的引用，它坚决指向旧版本，无论 GAC 中、搜索路径中等中有什么。对 .dproj 文件进行多次修改重新启动都不会起作用。
我最终发现，保留旧引用的有问题的部分是在 C:\Users\Public\documents\rad studio\5.0\dcp 目录中生成的 Oracle.DataAccess.dcpil。
它已经存在一年多了 - 无论情况如何，Delphi 都不想重写它。
一旦我删除了它，Delphi 就愉快地创建了另一个，果然，它现在指向我想要的程序集。
呃，令人沮丧！
I ran into something very much like this, and it drove me absolutely up the wall for days. I had a reference to Oracle.DataAccess.dll that was resolutely stuck pointing at an old version, regardless of what was in the GAC, in the search path, etc. No amount of restarts of modifications to the .dproj files would ever work.
What I eventually found was that the offending piece that was holding on to the old reference was the generated Oracle.DataAccess.dcpil in the C:\Users\Public\documents\rad studio\5.0\dcp directory.
It was over a year old - whatever the case was, Delphi did not want to write over it.
Once I deleted it, Delphi merrily created another one, and sure enough, it now points to the assembly I want it to.
Ugh, frustrating!