奇怪的ASP.NET AJAX Bug / 32位到64位

时间:2009-01-08 02:42:20

标签: asp.net-ajax 64-bit

自升级到Windows 2008 64位以来,我的网站出现了一个奇怪的错误。我的大多数应用程序池都以64位模式运行(除了一个之外,所有应用程序池都用于传统的ASP.NET 1.1应用程序)。在64位运行的站点上,我一直在从ASP.NET AJAX中收到错误。

Exception information:
   Exception type: System.NotSupportedException
   Exception message: Assembly "AjaxControlToolkit, Version=3.0.20820.16598, Culture=neutral, PublicKeyToken=28f01b0e84b6d53e" does not contain a script with hash code "e2e86ef9".

Request information:
   Request URL: http://site.com/page.aspx?_TSM_HiddenField_=ctl00_ctl00_elScripto_HiddenField&_TSM_CombinedScripts_=%3B%3BAjaxControlToolkit%2C+Version%3D3.0.20820.16598%2C+Culture%3Dneutral%2C+PublicKeyToken%3D28f01b0e84b6d53e%3Afr-FR%3A707835dd-fa4b-41d1-89e7-6df5d518ffb5%3Ae2e86ef9%3A9ea3f0e2%3A9e8e87e9%3A1df13a87%3Ad7738de7

Thread information:
   Thread ID: 21
   Thread account name: NT AUTHORITY\NETWORK SERVICE
   Is impersonating: False
   Stack trace:    at AjaxControlToolkit.ToolkitScriptManager.DeserializeScriptEntries(String serializedScriptEntries, Boolean loaded) in c:\AjaxControlToolkit_Admin\Release\AjaxControlToolkit\ToolkitScriptManager\ToolkitScriptManager.cs:line 534
  at AjaxControlToolkit.ToolkitScriptManager.OutputCombinedScriptFile(HttpContext context) in c:\AjaxControlToolkit_Admin\Release\AjaxControlToolkit\ToolkitScriptManager\ToolkitScriptManager.cs:line 264
  at AjaxControlToolkit.ToolkitScriptManager.OnInit(EventArgs e) in c:\AjaxControlToolkit_Admin\Release\AjaxControlToolkit\ToolkitScriptManager\ToolkitScriptManager.cs:line 198
  at System.Web.UI.Control.InitRecursive(Control namingContainer)
  at System.Web.UI.Control.InitRecursive(Control namingContainer)
  at System.Web.UI.Control.InitRecursive(Control namingContainer)
  at System.Web.UI.Control.InitRecursive(Control namingContainer)
  at System.Web.UI.Control.InitRecursive(Control namingContainer)
  at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

错误似乎是CodePlex中的已知问题,但这对我没有多大帮助。这是一个解释问题的链接: http://dotnetdebug.net/2008/05/25/ajaxcontroltoolkit-toolkitscriptmanager-stringgethashcode-and-mixing-32bit-and-64bit-machinesprocesses/

我没有使用负载平衡,我想知道为什么我的应用程序将在32位和64位模式之间切换。

难道必须为64位架构或类似的东西编译DLL吗?我应该注意哪些奇怪的问题可能导致我这个问题?

1 个答案:

答案 0 :(得分:3)

看起来String.GetHashCode()结果会根据编译dll的指令集而发生变化。当你的.NET 2.0+应用程序池都是64位时,我无法解释为什么会在框架内发生这种情况,但是如果你愿意从codeplex中获取最新的源代码并在ToolkitScriptManager。

我不知道为什么没有根据可用的评论提交官方修复 - 也许是因为所有的解决方案都像我的一样丑陋?

我试图通过使用其中一条注释中描述的SHA1哈希例程来修复它 - 所以首先我在ToolkitScriptManager类中创建了一个SHA1Managed提供程序的静态实例,如下所示:

public class ToolkitScriptManager : ScriptManager
{
    private static System.Security.Cryptography.SHA1Managed s = new System.Security.Cryptography.SHA1Managed();

...

然后有两个地方使用了我注释掉并替换的字符串哈希码 - 一次在SerializeScriptEntries函数中:

//serializedScriptEntries.Append(scriptEntry.Name.GetHashCode().ToString("x", CultureInfo.InvariantCulture));
serializedScriptEntries.Append(Convert.ToBase64String(s.ComputeHash(System.Text.Encoding.UTF8.GetBytes(scriptEntry.Name))));

然后在DeserializeScriptEntries函数中执行一次:

//string hashCode = resourceName.GetHashCode().ToString("x", CultureInfo.InvariantCulture);
string hashCode = Convert.ToBase64String(s.ComputeHash(System.Text.Encoding.UTF8.GetBytes(resourceName)));

也许一个更简单的方法可以让我们只访问64位GetHashCode方法来序列化这个字符串,这样我们就能得到32位和64位调用相同的结果......