摘要:今天同事在把一个Web项目从 Web Site 升级成 Web Application 应用后部署的时候，报错： Server Error in '/' Application.--------------------------------------------------------------------------------Parser Error Description: An error occurred during the parsing of a resource required to service this request. Please review the following specific parse error details and modify your source file appropriately. Parser Error Message: The file '/index.aspx.cs' does not exist.Source Error: Line 1:  <%@ Page Language="C#" AutoEventWireup="true" CodeFile ="index.aspx.cs" Inherits="Community.IndexHomePage.index" %>Line 2:  原因就是不知道为啥，采用系统升级工具，没有把这个Web Page 的 CodeFile 变成 CodeBehind 。而且仅仅只是这一个页面没升级，其他页面都升级了。再加上这两个属性都是 Code 开头的，一不留神，就会觉得一个属性。结果忙活了一回。 CodeFile 与 CodeBehind 在使用上是有很大区别的 先看 MSDN 上的说明： CodeBehind 指定包含与页关联的类的已编译文件的名称。该属性不能在运行时使用。Specifies the name of the compiled file that contains the class associated with the control. This attribute is not used at run time. CodeFile......[阅读全文]

摘要:情况一，依赖于一个文件的缓存先来看一段代码， 我们实现了一个依赖文件的过期缓存： protected void Page_Load(object sender, EventArgs e) ...{ System.Web.Caching.Cache c = HttpRuntime.Cache; string key = "123"; object o = c[key]; if (o == null) ......[阅读全文]

摘要:已经有人说过这个话题，相关链接： HttpRuntime.Cache vs. HttpContext.Current.Cachehttp://weblogs.asp.net/pjohnson/archive/2006/02/06/437559.aspx HttpContext.Cache和HttpRuntime.Cache http://blog.joycode.com/dotey/archive/2005/01/15/43091.aspx 我这里要说的是从另外一个角度来说： 一，两个实现代码的差异：我们用 .NET Reflector  看 HttpContext 类的 Cache 属性 ，会看到如下代码：public Cache Cache ...{ get ...{ return HttpRuntime.Cache; } } 所以，两者在代码上是完全一致的。 二、两者的差异其实在于 HttpContext.Current 用 .NET Reflector  看 HttpContext.Current 如下：public static HttpContext Current ...{ get ...{ return (ContextBase.Current as HttpContext); } } ContextBase 类的静态属性 ......[阅读全文]

摘要:网站的配置文件，可不仅仅只有 Web.config 一种，还有很多其他的，下面就来分析常见的几种。 一、Web.Config 的启示Web.config 的好处就不用说了，下面说他其中的几个限制。 1、对于Web 应用程序来说，修改web.config 文件，会让Web 应用自动重起。 如果我们某个配置，预计到会时常变更，或者不希望修改后，Web 应用就自动重起。就不应该把他配置在 Web.config 中。 举例：ASP.net 2.0 中新增的 SiteMap 配置文件，显然你一个站点有哪些文件配置信息会比较频繁变更，而且这里的修改，是不应该让站点重起的。微软也就没把这个配置放到 Web.config 中。当然没放到一起还有其他考虑，后面会提到。 参看：AppDomain 重新启动可能是基于以下因素： 1、 各种属性 （例如, memoryLimit 属性）被修改，配置文件 节中设置被修改。 2、 Global.asax 或 Web.config 文件修改。 3、 修改 Web 应用程序的 Bin 目录。 4、 病毒扫描软件触及一些 .config fileshttp://support.microsoft.com/kb/324772/zh-cnhttp://support.microsoft.com/default.aspx?scid=kb;EN-US;q324772 2、Web.config 文件不应该太大否则微软干么还要设置成，每个目录下都可以放一个 Web.config 文件。不把这些配置都放到一个文件下呢？？上面提到的 SiteMap 配置文件独立出来的一个考虑就是 SiteMap 文件可能会很大，另外，用户需要把 SiteMap 作为一个数据源来处理的需求很强烈，所以才会有 SiteMapDataSource Web 服务器控件。紧密跟 SiteMap 文件捆绑。这种特殊需求导致了不把这个信息放到 web.config 中。二、用自定义配置节、配置节组、配置处理程序声明方式来配置的读写操作。这套工作机制，就是 Web.config 内在的读写机制， Web.config 的配置是在这套基础上，增加了监控文件改变等逻辑操作的处理机制。 这套机制配置文件的格式：所有的配置信息都驻留在配置文件中的 configuration 元素中。此元素中的配置信息分为两个主区域：配置节处理程序声明区域和配置节设置区域。 新增或者调整一个配置时候，需要做的工作：1、调整新的配置节、配置节组类，确保满足新的，调整后的架构。所有的这些配置节类都必须从 ConfigurationElement 、 ConfigurationElementCollection 、ConfigurationSection 其中之一的类所派生。每一个配置节一个类，所以你的一个配置需求，可能最后会演变成多个配置类。2、修改配置文件：这里包含两部分：2.1、调整配置节处理程序声明，确保你新的配置结构声明正确。2.2、调整具体配置值上述步骤中，在具体调整配置时候，可能有些步骤不需要调整。 这套机制的局限性：1、每个配置节点都需要一个配置类对应，这个节点的父类只能是 ConfigurationElement 、 ConfigurationElementCollection 、ConfigurationSection 其中之一。2、一个业务逻辑的配置需求，可能需要多个配置节点配制类对应。3、业务逻辑类和业务逻辑设置类，绝大多数情况下必须分离，无法整合到同一个类中。4、配置文件中必须有配置数据提供者声明。5、新增或者调整一个配置结构比较复杂，有大量实体类需要实现，但是如果这个配置已经实现后，修改配置的值，则不具备复杂性。只需要修改一个地方即可。 所以这套配置机制不适合的几个场景如下：1、如果预计到，配置结构会不断变更，则不适合。每次变更修改的东西太多了。2、如果是一个小型应用，为了实现这种配置，额外的多了不少类，不划算。 但是如果是大型项目，而且设计定型了后，不会大变的情况下，则比较适合。也就是业务逻辑，和业务逻辑配置可预计的将来，不会发生大变化，则可接受。 三、 Community Server 中 communityserver.config 配置文件的读取方式。即，把配置文件当 XML 文件来读些，这时候我们就可以把业务类和配置紧密捆绑在一起了。 下面我们看看具体 Community Server 是如何做的。communityserver.config 配置文件对应的一个配置类 CSConfiguration 。CSConfiguration 把 communityserver.config 作为一个 XML 文件加载到 XmlDocument 对象中来，而这个 XmlDocument 对象的实例，又被缓存在内存中。 他的这部分实现代码如下：public static......[阅读全文]

摘要:Web.config 是可以配置在网站的任何一个目录下的，但是Web.config中一些配置项只能配置在某些特定目录下，这些配置项如果不是配置在某些特定目录下的时候，会报错，或者不起作用。 这些特殊的配置项，大多是做应用程序级别配置的配置项 比如：整个应用的验证模式配置项，如果你把它放在一个应用级别目录的下级目录时候。会报错。又比如，新加一个 HttpModule ，如果你把它放在一个应用级别目录的下级目录时候，会不起作用。但是，卸载一个 HttpModule 的配置，把它放在一个应用级别目录的下级目录时候，却起作用。 下面我们看一个对这个功能的测试我们有这样一个站点，如下图:  其中 MyWeb200 是一个站点 WebApp01 和 WebApp04 都是一个虚拟目录（Virtual Directory）虚拟目录 可以设置在跟根站点不在同一个目录下。他们的不同之处在于WebApp04 这个虚拟目录被设置了应用程序级别，WebApp01 没被设置，则这个目录下的应用程序级别是整个根站点下。可以明显看到 WebApp04 下有 bin 目录， WebApp01 下没有 WebApp02 和 WebApp03 都是站点下的一个子目录，他们的目录跟根站点的目录有从属关系。不同之于在于 WebApp02 设置了应用程序级别WebApp03 没被设置。 如果我们在上述所有目录下，都增加了一个 HttpModule，起作用的只有以下几个目录的配置，其他目录下不起作用。 根站点 Web.config 中新设一个 HttpModule 起作用WebApp01 虚拟目录下 Web.config 中新设一个 HttpModule 起作用WebApp02 子目录下 Web.config 中新设一个 HttpModule 起作用WebApp021 子目录下 Web.config 中新设一个 HttpModule 起作用 其他站点下 Web.config 中新设 HttpModule 不起作用，但是任何目录下，卸载一个指定的 HttpModule 起作用。 我上面用到的几个词的英文翻译： 虚拟目录 (Virtual Directory)子目录 (subdirectory)应用级别目录(application level) 参考： http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.public.dotnet.framework.aspnet&tid=3053b1b3-5edb-4716-99bc-cb476a61cf35&p=1一个简单的HttpModule例子http://www.cinenn.com/blog/105.shtml 总结：只有一句话。新增一个 HttpModule 只能是应用程序级别的设置，卸载一个 HttpModule 是目录层次的设置。...[阅读全文]

摘要:当我们把 Community Server 2.0 的数据库安装到 SQL 2005 数据库的时候，会收到很多如下的错误提示： Cannot grant, deny, or revoke permissions to sa, dbo, information_schema, sys, or yourself. 我们察看其中的安装 SQL 脚本，是如下的 SQL 导致错误发生的：declare @command nvarchar(4000) set @command = 'grant execute on [dbo].aspnet_RegisterSchemaVersion to ' + QUOTENAME(user) exec (@command) 这行代码，看逻辑，应该是 自己把权限分配给自己。这么写在 sql 2000 下没有问题，在 sql 2005 下就出错了。不过一般这个错误可以忽略不计。因为不影响我们其他的逻辑。 另外，如果你在运行基于 sql 2005 数据库的 Community Server 2.0 站点，运行时候如果发现有些存储过程由执行权限的错误报告，可以执行如下sql脚本修复这个已知的BUG。 据说这个 BUG 要在  Community Server 2.1 中才修复。grant execute on dbo.cs_BlogActivityReportAggregate_Get to public grant execute on dbo.cs_UserActivityReportRecords_Get to public grant execute on dbo.cs_Content_GetList to public grant execute on dbo.cs_PostAttachment_Delete to public grant execute on dbo.files_Entries_GetEntries to public grant execute on dbo.cs_PostAttachment_ToggleTemporary to public grant......[阅读全文]

摘要:问题演示以下代码只为问题演示，所以有些怪异的代码． 有这样的一个派生自System.Windows.Forms.Form 的类using System.Windows.Forms; public class MyForm : Form ...{ public string Info ...{ get ...{ if (MessageBox.Show("请选择", "选择", MessageBoxButtons.YesNo) == DialogResult.Yes) ......[阅读全文]

摘要:如果你使用企业库，一直运行在完全信任（full trust），则不需要这个 Patch。只有你需要运行在部分信任级别下时候，才需要这个补丁。 部分信任（partial trust）的典型场景是：ASP.net 应用。 这个补丁的下载地址：Patch 2554 for EntLib Jan 2006 - Partial Trust Support http://www.gotdotnet.com/codegallery/news/newsitem.aspx?id=295a464a-6072-4e25-94e2-91be63527327&newsId=8558c688-434b-4b32-b8af-799f681b8eca...[阅读全文]