我们在用C#开发程序的时候经常会遇到Session很不稳定，老是数据丢失。下面就是Session数据丢失的解决办法希望对您有好处。

1、在WEB.CONFIG文件中修改SESSION状态保存模式，如：<sessionState mode='StateServer' stateConnectionString='tcpip=127.0.0.1:42424' sqlConnectionString='data source=127.0.0.1;Trusted_Connection=yes' cookieless='true' timeout='180'/>

2、启动系统服务“ASP.NET状态服务 ”，系统默认是手动启动的

3、如果SESSION中保存的数据类型是自定义的，如结构，请在自定义数据类型处序列化会话状态，即在类或结构申明前加[Serializable]

完成以上3部，状态即可保存，但是在访问页面是浏览器显示的路径中增加了一段字符，如：(S(lto3j0eg25cztmqtxevm5tb4))

最近在做ASP.NET项目时，测试网站老是取不出Session中的值，在网上搜索了一下，找到一些解决方法，记录在这里。最后使用存储在StateServer中的办法解决了问题。

SessionState 的Timeout)，其主要原因有三种。 
一：有些杀病毒软件会去扫描您的Web.Config文件，那时Session肯定掉，这是微软的说法。 
二:程序内部里有让Session掉失的代码，及服务器内存不足产生的。 
三：程序有框架页面和跨域情况。 
第一种解决办法是:使杀病毒软件屏蔽扫描Web.Config文件(程序运行时自己也不要去编辑它) 
第二种是检查代码有无Session.Abandon()之类的。 
第三种是在Window服务中将ASP.NET State Service 启动。

下面是帮助中的内容: 
(ms-help://MS.VSCC.2003/MS.MSDNQTR.2003FEB.2052/cpguide/html/cpconsessionstate.htm) 
ASP.NET 提供一个简单、易于使用的会话状态模型，您可以使用该模型跨多个 Web 请求存储任意数据和对象。它使用基于字典的、内存中的对象引用（这些对象引用存在于 IIS 进程中）缓存来完成该操作。使用进程内会话状态模式时请考虑下面的限制：

使用进程内会话状态模式时，如果 aspnet_wp.exe 或应用程序域重新启动，则会话状态数据将丢失。这些重新启动通常会在下面的情况中发生： 
在应用程序的 Web.config 文件的 <processModel> 元素中，设置一个导致新进程在条件被满足时启动的属性，例如 memoryLimit。 
修改 Global.asax 或 Web.config 文件。 
更改到 Web 应用程序的 \Bin 目录。 
用杀毒软件扫描并修改 Global.asax 文件、Web.config 文件或 Web 应用程序的 \Bin 目录下的文件。 
如果在应用程序的 Web.config 文件的 <processModel> 元素中启用了网络园模式，请不要使用进程内会话状态模式。否则将发生随机数据丢失。

还有这二种：

一：在第一个页面置了SESSION，然后REDIRECT去第二个页面。解决方法是在REDIRECT中设置endResponse为FALSE。

二： ASP.NET中使用了ACCESS数据库，而且数据库是放在bin目录中的。解决方法是不要放会更新的文件在BIN目录中。

参考：http://www.dotnet247.com/247reference/msgs/58/290316.aspx

Asp.net 默认配置下，Session莫名丢失的原因及解决办法

正常操作情况下Session会无故丢失。因为程序是在不停的被操作，排除Session超时的可能。另外，Session超时时间被设定成60分钟，不会这么快就超时的。

这次到CSDN上搜了一下帖子，发现好多人在讨论这个问题，然后我又google了一下，发现微软网站上也有类似的内容。

现在我就把原因和解决办法写出来。

原因：

由于Asp.net程序是默认配置，所以Web.Config文件中关于Session的设定如下： 
<sessionState mode='InProc' stateConnectionString='tcpip=127.0.0.1:42424' sqlConnectionString='data source=127.0.0.1;Trusted_Connection=yes' cookieless='true' timeout='60'/>

我们会发现sessionState标签中有个属性mode，它可以有3种取值：InProc、StateServer?SQLServer（大小写敏感） 。默认情况下是InProc，也就是将Session保存在进程内（IIS5是aspnet_wp.exe，而IIS6是W3wp.exe），这个进程不稳定，在某些事件发生时，进程会重起，所以造成了存储在该进程内的Session丢失。

哪些情况下该进程会重起呢？微软的一篇文章告诉了我们： 
1、配置文件中processModel标签的memoryLimit属性 
2、Global.asax或者Web.config文件被更改 
3、Bin文件夹中的Web程序（DLL）被修改 
4、杀毒软件扫描了一些.config文件。 
更多的信息请参考PRB: Session variables are lost intermittently in ASP.NET applications

解决办法：

前面说到的sessionState标签中mode属性可以有三个取值，除了InProc之外，还可以为StateServer、SQLServer。这两种存Session的方法都是进程外的，所以当aspnet_wp.exe重起的时候，不会影响到Session。

现在请将mode设定为StateServer。StateServer是本机的一个服务，可以在系统服务里看到服务名为ASP.NET State Service的服务，默认情况是不启动的。当我们设定mode为StateServer之后，请手工将该服务启动。

这样，我们就能利用本机的StateService来存储Session了，除非电脑重启或者StateService崩掉，否则Session是不会丢的（因Session超时被丢弃是正常的）。

除此之外，我们还可以将Session通过其他电脑的StateService来保存。具体的修改是这样的。同样还在sessionState标签中，有个stateConnectionString='tcpip=127.0.0.1:42424'属性，其中有个ip地址，默认为本机（127.0.0.1），你可以将其改成你所知的运行了StateService服务的电脑IP，这样就可以实现位于不同电脑上的Asp.net程序互通Session了。

如果你有更高的要求，需要在服务期重启时Session也不丢失，可以考虑将mode设定成SQLServer，同样需要修改sqlConnectionString属性。关于使用SQLServer保存Session的操作，请访问这里。

在使用StateServer或者SQLServer存储Session时，所有需要保存到Session的对象除了基本数据类型（默认的数据类型，如int、string等）外，都必须序列化。只需将[Serializable]标签放到要序列化的类前就可以了。 
如： 
[Serializable] 
public class MyClass

...... 
}

3. 相同点和不同点

3.1 相同点

●都不能被直接实例化，都可以通过继承实现其抽象方法。 
●都是面向抽象编程的技术基础，实现了诸多的设计模式。

3.2 不同点

●接口支持多继承；抽象类不能实现多继承。 
●接口只能定义抽象规则；抽象类既可以定义规则，还可能提供已实现的成员。 
●接口是一组行为规范；抽象类是一个不完全的类，着重族的概念。 
●接口可以用于支持回调；抽象类不能实现回调，因为继承不支持。 
●接口只包含方法、属性、索引器、事件的签名，但不能定义字段和包含实现的方法；抽象类可以定义字段、属性、包含有实现的方法。  
●接口可以作用于值类型和引用类型；抽象类只能作用于引用类型。例如，Struct就可以继承接口，而不能继承类。

通过相同与不同的比较，我们只能说接口和抽象类，各有所长，但无优略。在实际的编程实践中，我们要视具体情况来酌情量才，但是以下的经验和积累，或 许能给大家一些启示，除了我的一些积累之外，很多都来源于经典，我相信经得起考验。所以在规则与场合中，我们学习这些经典，最重要的是学以致用，当然我将 以一家之言博大家之笑，看官请继续。

3.3 规则与场合

1.请记住，面向对象思想的一个最重要的原则就是：面向接口编程。 
2.借助接口和抽象类，23个设计模式中的很多思想被巧妙的实现了，我认为其精髓简单说来就是：面向抽象编程。 
3.抽象类应主要用于关系密切的对象，而接口最适合为不相关的类提供通用功能。 
4.接口着重于CAN-DO关系类型，而抽象类则偏重于IS-A式的关系； 
5.接口多定义对象的行为；抽象类多定义对象的属性；  
6.接口定义可以使用public、protected、internal 和private修饰符，但是几乎所有的接口都定义为public，原因就不必多说了。 
7.“接口不变”，是应该考虑的重要因素。所以，在由接口增加扩展时，应该增加新的接口，而不能更改现有接口。 
8.尽量将接口设计成功能单一的功能块，以.NET Framework为例，IDisposable、IDisposable、IComparable、IEquatable、IEnumerable等都只包含一个公共方法。 
9.接口名称前面的大写字母“I”是一个约定，正如字段名以下划线开头一样，请坚持这些原则。 
10.在接口中，所有的方法都默认为public。  
11. 如果预计会出现版本问题，可以创建“抽象类”。例如，创建了狗（Dog）、鸡（Chicken）和鸭（Duck），那么应该考虑抽象出动物 （Animal）来应对以后可能出现风马牛的事情。而向接口中添加新成员则会强制要求修改所有派生类，并重新编译，所以版本式的问题最好以抽象类来实现。

12.从抽象类派生的非抽象类必须包括继承的所有抽象方法和抽象访问器的实实现。 
13.对抽象类不能使用new关键字，也不能被密封，原因是抽象类不能被实例化。 
14.在抽象方法声明中不能使用 static 或 virtual 修饰符。

以上的规则，我就厚颜无耻的暂定为T14条吧，写的这么累，就当一时的奖赏吧。大家也可以互通有无，我将及时修订。

4. 经典示例

4.1 绝对经典

.NET Framework是学习的最好资源，有意识的研究FCL是每个.NET程序员的必修课，关于接口和抽象类在FCL中的使用，我有以下的建议：

1.FCL对集合类使用了基于接口的设计，所以请关注System.Collections中关于接口的设计实现； 
2.FCL对数据流相关类使用了基于抽象类的设计，所以请关注System.IO.Stream类的抽象类设计机制。