使用VS 2008创建web应用有两种方式：

1. 创建webapplication。

2. 创建网站。

可以发现，webapplication方式和普通的项目没有多大区别，而使用“新建网站”的方式可以选择http，或文件系统。其中http是会在iis上建立web应用程序，当然要保证iis已经安装；而文件系统是使用的vs自带的web服务器，没有使用IIS。

两种方式的区别还在与开发过程中：

webapplication中新加一个aspx页面会生成一个.designer.cs文件，打开可以发现，里面主要是用于声明控件变量，事件绑定等，他和aspx.cs文件配合使用，只为将控件声明和事件绑定与实际事件分离，编译时会合并；如果使用VS 2003就会发现,vs 2003的网站也没有.designer.cs文件，但是在aspx.cs文件里面你会看到繁琐的控件声明和事件绑定。

webapplication在修改.cs文件后需要编译，才能在浏览器下浏览；而新建网站方式，可以直接浏览不需要编译，实际上是，在你浏览时候会自动编译。

webapplication下你可以任意创建目录，并在目录里面直接添加.cs文件，并且.cs文件的命名控件会自动为目录名.文件名。例如目录User下面创建Membership.cs文件，那么访问Membership时就是User.Membership；而且创建的aspx页面生成的.aspx.cs文件也会添加命名空间的；而在新建网站方式下，是建议将所以.cs文件（非.aspx.cs文件）放在专用目录App_Code下，而且默认没有命名空间，而且新建的aspx文件时，生成的.aspx.cs文件的是没有命名控件的，是一目录名加下划线，然后加文件名的形式。如User目录下的Default.aspx.cs文件，生成的类就是User_Default；因此在webapplication下是可以通过User.Default来访问该页面下定义的方法，而网站形式下就不能了。

另外有一个问题值得注意，就是.designer.cs文件的内容也是vs自带添加的，但有时候它会失灵，但我往aspx文件里面拖拽了一控件后，发现.designer.cs文件并没有变化，没有把控件的声明添加进去，这时如果在aspx.cs文件中使用这个控件的时候没有智能提示，原因是没有声明。解决该问题的一个方法是：关闭.designer.cs文件，在aspx文件的设计试图中，“右键”->“刷新”。

发布ASP.NET2.0应用时候出现错误：

无法序列化会话状态。在“StateServer”或“SQLServer”模式下，ASP_NET 将序列化会话状态对象，因此不允许使用无法序列化的对象或 MarshalByRef 对象。如果自定义会话状态存储在“Custom”模式下执行了类似的序列化，则适用同样的限制。

而在开发模式下是没有问题的。

查看异常描述可以发现“StateServer”和“SQLServer”模式等字眼，在web.config文件中可以发现，<sessionState mode="StateServer"/>，将该句去掉或将"StateServer"或"SQLServer"改成”InProc“可以解决该问题。

刚进公司就被发配到合肥了，搬搬手指脚趾算算都1个半月了，住了这么久的7天酒店，也吃了这么久的华安不错饭菜，肚子也略有微起了，尽管每天下午还是胃胀，胃疼，但这里的伙食确实不错，如果上海没有家，还真舍不得离开这里。

项目已接近收尾，上周六开始部署正式环境，测试环境运行一切正常，但到了正式环境确歇菜了。最大的问题的是没有提示错误，仅仅是空白的页面。但是访问不需要权限的页面还是可以正常访问，所以可以下定论是出在恒生接口上，对接口的封装错误，或是接口本身错误，不过接口本身错误的可能行比较小。重新注册了COM接口，正常了。

不过运行到下午，在整理正式环境上的文件的时候，系统有歇菜了，难道是我们动了相关的文件了。但文件都彻底删除了。问题有要找啊找，熬到晚上7点半，终于重新注册COM接口，系统正常。原来，反复重新注册都没有用的原因是COM接口注册错了。中午歇菜的原因是把COM接口的ddl文件也删了。

周日发现，在王哥机器上访问登陆页面时总是报验证码错误，之前也是这样，但在我机器上确没有，其他同事也有类似错误。该登陆界面是客服平台的登陆页面，通过iframe镶嵌在网站上的，初步猜测是跨域访问，浏览器设置的问题。但是当时没有在意，现在部署到正式环境下就不能不当回事了。幸好老大这周过来了，一下就命中问题所在，就在网上找了解决方案，方案很简单就是在页面中加一行代码即可。就是在iframe内页中添加Response.AddHeader("P3P","CP=CAO PSA OUR");一行代码，可是内外页面都试了，还是不行，但是问题肯定可以通过类似解决方案解决。

后来就正对iframe跨域访问cookie的解决方法来google解决方案，最终找到方法，针对iframe内页操作：

1. Response.AddHeader("P3P","CP=CAO PSA OUR");
2. 打开IIS
管理工具——〉选择一个网站——〉属性——〉http头，增加一个http头
然后输入头名：P3P
输入头内容：CP=CAO PSA OUR

问题解决。

原文地址：http://www.alrond.com/en/2007/jan/25/performance-test-of-6-leading-frameworks/

原文对六种流行的WEB开发框架进行了简单的性能测试，比较的标准首先是大流量下的稳定性，其次是性能。测试的方法很简单，页面只输出一个Hello world字符串，不涉及任何数据库操作，否则整个网站的性能就会因为数据库的影响而趋向于集中。

测试用的硬件和系统：
CPU: AMD OpteronT Processor 146 (2 GHz)
Memory: 2 GB
OS: Debian 3.1 (Linux 2.6.14)
Web-Server: nginx/0.5.5

测试软件：
Siege 2.65 http://www.joedog.org/JoeDog/Siege
Http_load 12.03.2006 http://www.acme.com/software/http_load/
ab 2.0.41-dev Rev: 1.141

这套硬件和软件系统应该说还是相当有代表性的，所以其结果很值得参考。具体的测试参数和测试细节还有结果的详细数字和图标可以到原文链接去看，这里只讲一下最终的结果。

第一名：Django 占用CPU最少，性能超过第二名好几倍，使用threaded模式比prefork模式要快15%左右，（在一个中国的作者的测试情况下，threaded模式比prefork模式快近十倍），但是在高负载的情况下，threaded模式会死掉，而且无法自动重启，必须手工重启WEB 服务器，这对于生产环境服务器是不可接受的。另外，使用Psyco来加速的话，两种方式下速度都可以提高20%左右，但是内存占用量会增加1-3倍，如果硬件资源没问题，就可以考虑这种方式。

第二名和第三名分别是TurboGears和RoR 1.1.6，它们速度差不多，但是不同负载量下的表现不同。
RoR 1.2.1的速度比1.1.6要慢2-4倍，而且在高负载下CPU占用也大一倍。

PHP的框架速度是最慢的，比Django慢了35倍。但是在加载了eAccelerator加速器以后速度有大幅提升，只比Django慢两倍了。

作者后来又做了一次额外测试，增加了几个新兴的框架，但是最终结果并没有变，还是证明Django是最佳选择。而且，Python非常容易上手。另外，同样基于Python的框架Pylons也不错。

http://blog.csdn.net/guangboo/archive/2007/12/29/2003211.aspx