升级到 .net 4.0 后无法加载文件或程序集“AjaxControlToolkit”答案

【问题标题】：Could not load file or assembly 'AjaxControlToolkit' after upgrade to .net 4.0升级到 .net 4.0 后无法加载文件或程序集“AjaxControlToolkit”
【发布时间】：2010-12-26 15:09:09
【问题描述】：

我有一个正在尝试升级到 .net 4.0 的 Web 应用程序。

我使用该应用程序并通过 Visual Studio 2010 Beta 2 打开它，并选择了该应用程序的升级路径。该应用程序使用 AjaxControlToolkit。现在，当我尝试访问页面时升级已完成，我收到错误消息：“无法加载文件或程序集 'AjaxControlToolkit' 或其依赖项之一。访问被拒绝。”

我试过了：

重启我的机器
清洁解决方案
删除临时 ASP.Net 文件中的所有文件
在 Bin 目录、Temporary ASP.Net Files 目录中放宽权限（添加具有完全控制权的所有人）
删除和读取对 AjaxControlToolkit DLL 的引用

AjackControlToolkit 的相关 web.config 条目是：

<pages controlRenderingCompatibilityVersion="3.5" clientIDMode="AutoID">
  <controls>
    <add tagPrefix="ajaxToolkit" namespace="AjaxControlToolkit" assembly="AjaxControlToolkit"/>
  </controls>
</pages>

关于这里发生的事情/如何解决此问题的任何想法？

【问题讨论】：

+1：快速测试查看它是否与用户模拟权限相关是为您的模拟帐户授予本地管理员权限。如果问题消失，您需要为该帐户分配特定的访问权限以访问 IIS 文件。
对于其他已完成所有建议但仍有问题的人，此链接可能会引起您的兴趣。 stackoverflow.com/a/23534971/1027250

标签： asp.net ajaxcontroltoolkit .net-4.0-beta-2

【解决方案1】：

我意识到已经有一个公认的答案，但是对于通过搜索错误代码访问此页面的其他人......

查看您尝试模拟的用户的权限。

在我的情况下，我只是在我的开发机器上收到错误，而不是在我们的登台或部署服务器上。（虽然我通过在我的开发环境中从配置中删除“身份”节点并只是在构建后添加该行来解决这个问题，所以这对我以外的任何人来说都不是问题..

在我的环境中，我们有一个特定用户，我们的所有网络应用程序在运行时都会模拟该用户。我已经创建了用户帐户，但没有明确设置其帐户权限。当我在我的开发机器上将用户添加为管理员时，这个问题完全消失了。（不理想，我知道，但它“对我有用”，并且伤害很小，因为该用户帐户无论如何都被锁定在我们的“真实”服务器上......）

【讨论】：

【解决方案2】：

记得使用上下文菜单[右键单击]以“以管理员身份运行”打开“Visual Studio”。

【讨论】：

【解决方案3】：

检查 DLL 的属性。如果它在某处声明“此文件来自另一台计算机”，请单击复选框并“应用”，以解除 Windows 设置的限制。

【讨论】：

【解决方案4】：

我遇到了同样的问题。经过大量研究，我发现我在配置文件中使用了模拟。我不得不将模拟 ID 更改为服务器本地的其他用户，它立即解决了问题。

【讨论】：

【解决方案5】：

你可以试试这个： C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\ 。只需清理此文件夹中的所有文件夹和文件并编译您的应用程序。编码愉快！

【讨论】：

【解决方案6】：

当我在新的 Windows Server 2008 机器上重新安装我的 ASP.NET 应用程序时，我收到了这个错误消息（尽管是另一个 dll 文件）。我花了几个小时寻找解决方案，尝试了一切，但无济于事。直到我停用 McAfee 防病毒软件。当我这样做时，一切都像魅力一样。

【讨论】：

【解决方案7】：

我尝试向我的模拟用户授予对 Temporary ASP.NET Files 文件夹的完全权限，但这没有奏效。我记得过去当我遇到这个错误时，它确实起到了作用。

我知道问题发布者尝试过这个，但是当我在 Visual Studio 中删除/添加 AjaxToolKit 时它对我有用。我建议先尝试他所做的一切。我希望这对某人有所帮助。

【讨论】：

【解决方案8】：

我认为关于 C:\Windows\Microsoft.NET\Framework64\v4.0.21006\Temporary ASP.NET Files[projectName] 中的临时文件的帖子是正确的。

我通过编辑权限解决了这个问题，以确保 ASP Impersonating 用户（在 IIS 的安全部分中作为允许匿名访问时应用程序应使用的匿名用户找到）对目录具有适当的安全性。

解决了问题...拒绝访问通常指向权限问题。

【讨论】：

【解决方案9】：

我遇到了类似的问题，但通过为我的模拟身份授予对“临时 ASP.NET 文件”文件夹的完全权限来解决。

【讨论】：

我通过将模拟用户添加到我的 Vista 工作站上的 IIS_IUSRS 组来解决此问题。
我知道这是一个旧线程，但我在这里发表评论只是为了强调这个答案和 jrummell 的评论。将模拟用户添加到 IIS_IUSRS 组可提供对 Temporary ASP.NET Files 目录的完全访问权限。它还有什么作用？我不知道，但我认为这是一种比仅授予该目录特定权限更“正确”的方法。用户需要哪些其他权限才能运行 ASP.NET 应用程序？不知道，不过这个群应该有吧？
类似：对我来说，它给了模拟用户（如果 web.config 有 impersonate=true 但没有，那就是 IUSR_[machinename] t 指定用户名）修改、读取和执行我的网络应用文件夹的权限并确保这些权限传播到所有子文件夹（单击高级按钮）。
我遇到了这个确切的问题，Jeremy 的解决方案对我有用。我尝试在 Web 根目录以及所有子文件夹和文件上授予模拟用户完全控制权，但没有任何改变。然后我尝试在“C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files”文件夹上授予模拟用户完全控制权，这为我解决了这个问题。
与 Jeremy 和 Josh 一起，我可以确认此解决方案适用于 .NET 4.5.2。

【解决方案10】：

不是 100% 确定为什么会这样，而是在适当的 Temporary ASP.Net Files 目录（位于：C:\Windows\Microsoft.NET\Framework64\v4.0.21006\Temporary ASP.NET Files[projectName]）中手动复制 AjaxControlToolkit.dll。

然后我看到了其他缺少的 DLL，但是在手动将它们复制到此位置后，我也能够解决这些问题。似乎不是最好的答案，但它最终对我有用。

【讨论】：

只是出于好奇，您有没有试过只删除所有临时文件？
我确实尝试删除所有临时文件，但没有成功

【解决方案11】：

奇怪的错误。您的 web.config 文件中是否有任何内容指向 AjaxControlToolkit，并提供了公钥令牌或其他程序集规范？这发生在我身上，其中一个值发生了变化，或者我从 GAC 中的引用更改为本地引用...

HTH。

【讨论】：