从.NET 3.0升级到3.5：在网络花园中，设置为asteserver的站点还原为Inproc

Question

设想：

以运行.NET 3.0的服务器和ASP.NET网站在启用Web花园的应用程序池中运行（流程数：3）。 Web.config配置如下：

    <sessionState
      cookieless="UseCookies"
      cookieName=".authz"
      mode="StateServer"
      regenerateExpiredSessionId="true"
      stateConnectionString="tcpip=127.0.0.1:42424"
      timeout="60"
      useHostingIdentity="true" />

现在将机器升级到.NET 3.5 SP1。重新启动服务器。结果：在W3WP.EXE的实例中不再维护会议，就好像所有播放都恢复为InProc一样。减少1个工作过程是当前的解决方法。

奇怪的是：不同服务器上的相同代码没有问题。我以前遇到了这个问题，但是重新启动后它神奇地消失了。我已经重新启动了一次，但是到目前为止还没有快乐。

比较两台服务器的两台机器和web.configs：相同。

其他人遇到了这个问题, ，但那里没有答案。

有任何想法吗？我是 真的 在这一个。

Answer 1

因此，这个真是太神奇了。

当以下所有条件均为真实时，似乎发生了问题：

• 您正在运行Windows Server 2003（IIS 6.0）和ASP.NET 2.0网站。
• 该网站配置为使用网络花园，其中最大工程进程数量大于1。因此，您已经配置了应用程序以使用处理外的会话存储；在这种情况下，在本地计算机上运行的ASP.NET状态服务。
• 应用程序池标识不是将网络服务设置为网络服务，而是为您创建的自定义，低特权的用户帐户 部署最佳实践.
• 您运行一个更新.NET框架的安装程序；就我而言，这是从.NET 3.0到.NET 3.5 SP1的更新。

当升级完成并重新启动服务器时，您会发现会话变量在刷新页面时经常丢失，因为只有三分之一的机会让您获得原始工作流程为您的原始请求服务。但这没关系，因为您正在使用ASP.NET州服务。什么破裂了？

使用ASP.NET状态服务时，ASP.NET使用称为称为的值 machineKey 要对所有会话数据进行加密和/或哈希（我不知道它是加密或哈希或两者兼而有之），但这并不是此讨论的重要区别）。这样一来，当任何工作流程都使用会话标识符从服务中索取数据时，可以确定数据在将其存储在外部数据源中时不会被篡改。

如果您在网络农场，那么您可能有一个静态的 machineKey 在您的中定义 web.config 文件，此问题不会发生。但是对于单服务器的网络花园场景，您可能依靠默认 machineKey 设置，设置为 AutoGenerate,IsolateApps 对于ASP.NET 2.0应用程序。这意味着ASP.NET会自动生成应用程序池独特的计算机密钥。它会根据某些算法再生该键，但这对于此讨论并不重要。

生成的值通常存储在注册表中 HKLM\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0\AutoGenKeys\{SID of the Application Pool Identity}. 。但是，.NET框架安装程序错误（我确实相信这是一个错误）会破坏此注册表密钥，并为了增加侮辱性的伤害，重置此密钥上的权限，以使您的自定义应用程序池标识不能在注册表条目中写入注册表条目。创建其新机器密钥。

结果是，在网上花园中插入的每个工艺过程都使用其自己的机器密钥的内存副本，该副本是及时生成的，有效地创建了网络农场场景。例如，工人处理A旋转，发现没有 AutoGenKey 存在（实际上，它都无法 读 IT），自行生成并开始使用它来发送到ASP.NET状态服务的哈希数据。它试图将此新机器键保存到注册表条目中，但会默默失败。工程流程B旋转，发现没有 AutoGenKey 进入，生成自己的，并开始使用 那 要进行哈希数据...您会看到这是在哪里。

结果是现在您使用了三个不同的机器键哈希的会话数据。尽管存在会话标识符的数据，但由于使用了自己的密钥，因此三分之二的工作过程中有两个会拒绝它是无效/篡改的。

您可以通过明确设置自定义来解决这个问题 machineKey 在你的 web.config 文件。

或者您可以重新运行 aspnet_regiis.exe -ga MachineName\ApplicationPoolUserName 在命令提示下，修复了损坏的权限。

您的问题得到了解决。该睡觉了。

---

6月30日更新： 根据我关于这个问题的报告 Microsoft Connect, ，微软表示他们已经修复了安装程序，以至于从升级到.NET 4开始就不会发生这种行为。所有未来的3.0/3.5升级仍然可能发生，因此我将离开这个问题/答案。