在我的应用程序的身份验证代码中，使用FormsAuthentication处理最复杂的部分，我已经将运行应用程序的某些计算机上的环境问题的可能罪魁祸首缩小到了BinaryFormatter。
在某些计算机上，身份验证过程正确完成并且我的用户已登录。但是，在其他计算机上，BinaryFormatter会产生来自相同输入的单独结果（几乎相同，除非我'缺少某些东西），从而打破了身份验证过程，用户永远无法登录。
在正确的环境中，它会生成一个长度约为 373 的序列化字符串。在错误环境中，生成的序列化字符串为 5,024 。这就是问题所在。
以下是代码的运行方式：
var formatter = new BinaryFormatter();
var buffer = new MemoryStream();
formatter.Serialize(buffer, HttpContext.Current.User);
这反过来又破坏了身份验证过程的其余部分，因为它实际上创建了一个包含大约40,000+字节数据的cookie，它从不创建cookie（需要4,096字节或更少才能被浏览器接受）。
我的问题，并且它不容易测试（告诉我） - 两台机器之间可能有什么不同导致序列化差异？两者都是在Visual Studio的Windows 7上开发并运行在内置的Cassini服务器上，但还有其他常见问题会使Serialize返回如此截然不同的结果吗？
答案 0 :(得分：0)
我的一位同事遇到了这个，似乎问题确实存在于序列化器中：
我尝试使用基于ASP.NET角色的authroization并需要生成 用于客户端浏览器的角色的cookie。当我提升.NET框架时 从v4.0到v4.5。不再生成cookie。经过测试 并检查，我发现这是因为返回的字符串文本 RolePrincipal.ToEncryptedTicket（）比以前长10倍 至少一个大于最大cookie长度4,096。这就是为什么 RoleManagerModule无法为asp.net角色生成cookie。什么时候 我卸载了.NET framework 4.5并重新安装了v4.0，它就变成了 正常情况再次。角色Cookie再次出现在客户端浏览器中
同样在该页面上是微软的回复说他们调查了它（该页面是一个错误报告）并且他们将其标记为已解决，因为这是设计的。
删除.NET 4.5和4.0然后重新安装4.0对我有用 - 暂时我的应用程序正常运行，我将重新审视auth部分，以解决这个问题，所以它可以在未来向前推进到4.5框架。