【问题标题】:MSBUILD 4.0 Fails on AJAX ExtensionsMSBUILD 4.0 在 AJAX 扩展上失败
【发布时间】:2011-02-27 08:22:10
【问题描述】:

我们有一个 .Net 2.0 Web 应用程序,并且正在将解决方案和项目转换为 Visual Studio 2010(它们是 Visual Studio 2005)。我们将离开以 Framework 2.0 为目标的项目。该应用程序包括 Ajax 扩展。我们进行了转换,可以使用 Visual Studio 在服务器上成功构建项目。但是,当我们尝试通过 MSBUILD 4.0 构建项目时,在使用 ajax 控件的页面上会出现错误,例如:

C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1360,9): 警告 MSB3267:主要参考 “System.Web.Extensions, 版本=1.0.61025.0,文化=中性, PublicKeyToken=31bf3856ad364e35, 处理器架构=MSIL”,即 框架组件,不能 在当前目标中解决 框架。 “.NETFramework,版本=v2.0”。到 解决这个问题,要么删除 参考“System.Web.Extensions, 版本=1.0.61025.0,文化=中性, PublicKeyToken=31bf3856ad364e35, 处理器架构=MSIL" 或 将您的应用程序重新定位到 包含的框架版本 “System.Web.Extensions, 版本=1.0.61025.0,文化=中性, PublicKeyToken=31bf3856ad364e35, 处理器架构 = MSIL”。 [C:\Inetpub\wwwroot\gmrcwebsite\GMRCWebsite.vbproj]

C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1360,9): 警告 MSB3268:主要参考 “System.Web.Extensions.Design, 版本=1.0.61025.0,文化=中性, PublicKeyToken=31bf3856ad364e35, 处理器架构 = MSIL”不能 被解决,因为它有一个间接的 对框架组件的依赖 “System.Web.Extensions, 版本=1.0.61025.0,文化=中性, PublicKeyToken=31bf3856ad364e35" 其中 目前无法解决 有针对性的框架。 “.NETFramework,版本=v2.0”。到 解决这个问题,要么删除 参考资料 “System.Web.Extensions.Design, 版本=1.0.61025.0,文化=中性, PublicKeyToken=31bf3856ad364e35, 处理器架构=MSIL" 或 将您的应用程序重新定位到 包含的框架版本 “System.Web.Extensions, 版本=1.0.61025.0,文化=中性, PublicKeyToken=31bf3856ad364e35"。 [C:\Inetpub\wwwroot\gmrcwebsite\GMRCWebsite.vbproj]

C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1360,9): 警告 MSB3268:主要参考 “AjaxControlToolkit, 版本=1.0.10618.0,文化=中性, PublicKeyToken=28f01b0e84b6d53e, 处理器架构 = MSIL”不能 被解决,因为它有一个间接的 对框架组件的依赖 “System.Web.Extensions, 版本=1.0.61025.0,文化=中性, PublicKeyToken=31bf3856ad364e35" 其中 目前无法解决 有针对性的框架。 “.NETFramework,版本=v2.0”。到 解决这个问题,要么删除 参考“AjaxControlToolkit, 版本=1.0.10618.0,文化=中性, PublicKeyToken=28f01b0e84b6d53e, 处理器架构=MSIL" 或 将您的应用程序重新定位到 包含的框架版本 “System.Web.Extensions, 版本=1.0.61025.0,文化=中性, PublicKeyToken=31bf3856ad364e35"。 [C:\Inetpub\wwwroot\gmrcwebsite\GMRCWebsite.vbproj]

C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1360,9): 警告 MSB3267:主要参考 “System.Web.Extensions.Design, 版本=1.0.61025.0,文化=中性, PublicKeyToken=31bf3856ad364e35, 处理器架构=MSIL”,即 框架组件,不能 在当前目标中解决 框架。 “.NETFramework,版本=v2.0”。到 解决这个问题,要么删除 参考资料 “System.Web.Extensions.Design, 版本=1.0.61025.0,文化=中性, PublicKeyToken=31bf3856ad364e35, 处理器架构=MSIL" 或 将您的应用程序重新定位到 包含的框架版本 “System.Web.Extensions.Design, 版本=1.0.61025.0,文化=中性, PublicKeyToken=31bf3856ad364e35, 处理器架构 = MSIL”。 [C:\Inetpub\wwwroot\gmrcwebsite\GMRCWebsite.vbproj]

C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1360,9): 警告 MSB3268:主要参考 “AjaxControlToolkit, 版本=1.0.10618.0,文化=中性, PublicKeyToken=28f01b0e84b6d53e, 处理器架构 = MSIL”不能 被解决,因为它有一个间接的 对框架组件的依赖 “System.Web.Extensions.Design, 版本=1.0.61025.0,文化=中性, PublicKeyToken=31bf3856ad364e35" 其中 目前无法解决 有针对性的框架。 “.NETFramework,版本=v2.0”。到 解决这个问题,要么删除 参考“AjaxControlToolkit, 版本=1.0.10618.0,文化=中性, PublicKeyToken=28f01b0e84b6d53e, 处理器架构=MSIL" 或 将您的应用程序重新定位到 包含的框架版本 “System.Web.Extensions.Design, 版本=1.0.61025.0,文化=中性, PublicKeyToken=31bf3856ad364e35"。 [C:\Inetpub\wwwroot\gmrcwebsite\GMRCWebsite.vbproj]

...

错误 BC30451: 'ScriptManager' 不是 宣布。由于可能无法访问 到它的保护水平。错误 BC30002:类型 'System.Web.UI.ScriptManager' 不是 定义。错误 BC30002:类型 'System.Web.UI.UpdatePanel' 不是 定义。错误 BC30002:类型 'System.Web.UI.UpdateProgress' 不是 已定义。

这些东西以前运行良好,通过 Visual Studio 构建时构建和运行良好。我们需要做什么来修复这些错误?

【问题讨论】:

  • 遇到同样的问题,由于同样的问题,我们的 Web 服务稍后将无法编译。

标签: visual-studio-2010 asp.net-ajax msbuild


【解决方案1】:

在将 TFS Build service 2008 配置为使用 MSBuild 4.0 后,我自己也遇到了同样的问题。在转换项目之前一切正常,然后转换为 2010 格式并切换到 MSBuild 4 突然找不到 1.0.61025.0 AJAX 库。

原来缺少一个指向 MS Ajax 扩展安装位置的注册表项。

在我的开发盒上,应该位于(64 位操作系统)的密钥

HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\.NETFramework\v2.0.50727\AssemblyFoldersEx\ASP.NET AJAX Extensions

改为放置在 HKEY_CURRENT_USER 中。 (32 位操作系统:去掉 Wow6432Node 部分)

构建服务器上,密钥完全丢失(本地存在的用户配置文件都没有在其注册表配置单元中)。

这个键的默认值应该指向 MS Ajax Extensions 安装目录,在我的例子中是

C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET 2.0 AJAX Extensions\v1.0.61025

在构建服务器上重新创建密钥后,我们的解决方案在 MSBuild 4 下成功构建。

直到现在(在 MSBuild 3.5 下)成功构建的原因对我来说仍然是个谜。也许程序集搜索算法略有变化,现在限制性更强。

希望对您有所帮助。

【讨论】:

  • +1 : 这对我有用 - 不知道为什么这有效或以前无效
  • 太棒了 - 就像克里斯所说的那样,为什么它以前有效!
  • 太棒了。非常感谢——这一下子解决了 30 分钟的头痛问题。 =)
【解决方案2】:

【讨论】:

    猜你喜欢
    • 2011-05-07
    • 1970-01-01
    • 2021-06-08
    • 2011-06-08
    • 2015-06-19
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多