若 要针对 .NET Framework 4.0 或更高版本进行编译，则提供程序选项中“compilerVersion”特性的值必须为“v4.0”或更高版本。若要针对 .NET Framework 3.5 或更低版本编译此 Web 应用程序，则请从 Web.config 文件的 <compilation> 元素中移除 targetFramework 特性。

解决办法：

在网站的Web.config中增加或修改configuration>system.codedom配置节

<system.codedom>
      <compilers>
         <compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CSharp.CSharpCodeProvider,System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" warningLevel="4">
             <providerOption name="CompilerVersion" value="v4.0"/>
             <providerOption name="WarnAsError" value="false"/>
       </compiler>
         <compiler language="vb;vbs;visualbasic;vbscript" extension=".vb" type="Microsoft.VisualBasic.VBCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" warningLevel="4">
          <providerOption name="CompilerVersion" value="v4.0"/>
          <providerOption name="OptionInfer" value="true"/>
          <providerOption name="WarnAsError" value="false"/>
         </compiler>
      </compilers>
  </system.codedom>

1、在资源管理器中打开你要作为常用保存位置的文件夹

2、在资源管理器左侧右键收藏夹，选择将当前位置添加到收藏夹；在收藏夹下面就会出现当前的文件名称，可以右键对它进行重命名

将文件夹添加到资源管理器收藏夹

 在Word等程序的保存窗口，就可以看到刚设置的常用文件夹了

Word保存窗口

对于个别像FastStone Capture的保存窗口不是用Windows 7通用文件保存对话框实现的，则需要借助于PlaceBar Editor。

参考：

1. 找回躲猫猫的Win7资源管理器收藏夹
2. Common File Dialog Box – Customize Places Bar

找不到存储过程 ‘dbo.aspnet_CheckSchemaVersion’

根据提示，通过数据库管理器建立这个存储过程就OK了，这个方法这里不提。但因为数据库是新建的，所以很可能有很多相关的存储过程都没有。于是找到了一下的方法：

运行C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regsql.exe ASP.NET SQL Server数据库安装向导来进行配置。

通过配置对应的数据库即可，问题解决。

找不到存储过程 ‘dbo.aspnet_Membership_GetUserByUserId’

根据提示，很显然数据库里缺少响应的存储过程，用数据库管理器打开对应的数据库执行以下sql语句即可。

SET QUOTED_IDENTIFIER OFF
GO

CREATE PROCEDURE dbo.aspnet_Membership_GetUserByUserId
    @UserId               uniqueidentifier,
    @CurrentTimeUtc       datetime,
    @UpdateLastActivity   bit = 0
AS
BEGIN
    IF ( @UpdateLastActivity = 1 )
    BEGIN
        UPDATE   dbo.aspnet_Users
        SET      LastActivityDate = @CurrentTimeUtc
        FROM     dbo.aspnet_Users
        WHERE    @UserId = UserId

        IF ( @@ROWCOUNT = 0 ) -- User ID not found
            RETURN -1
    END

    SELECT  m.Email, m.PasswordQuestion, m.Comment, m.IsApproved,
            m.CreateDate, m.LastLoginDate, u.LastActivityDate,
            m.LastPasswordChangedDate, u.UserName, m.IsLockedOut,
            m.LastLockoutDate
    FROM    dbo.aspnet_Users u, dbo.aspnet_Membership m
    WHERE   @UserId = u.UserId AND u.UserId = m.UserId

    IF ( @@ROWCOUNT = 0 ) -- User ID not found
       RETURN -1

    RETURN 0
END

GO

参考：[dbo].[aspnet_Membership_GetUserByUserId] ]]> http://witmax.cn/aspnet_membership_getuserbyuserid.html/feed 0 http://witmax.cn/discuz-invite-register-settings.html http://witmax.cn/discuz-invite-register-settings.html#comments Mon, 16 Jan 2012 05:08:22 +0000 晴枫 http://witmax.cn/?p=1907 对于封闭论坛来说不希望陌生用户注册进来，那么就可以关闭开发注册，而采用邀请注册的方式。具体设置如下：

管理员后台》全局》注册与访问》允许新用户注册》选择“只开放邀请注册”，如下图：

开启邀请注册设置

 回到论坛，在注册中心可以看到邀请注册链接，点击后打开如下：

邀请注册界面

 如没有看到购买邀请码的界面，说明用户所属的用户组没有邀请码购买权限，需要通过以下方法设置。

管理员后台》用户》管理组/用户组》编辑某一用户组》注册相关》进行相关的设置

允许用户组购买邀请码设置

 再次回到个人中心的邀请注册，此时可以看到邀请码购买界面了，搞定！

class(类)是面向对象编程的基本概念，是一种自定义数据结构类型，通常包含字段、属性、方法、构造函数、索引器、事件等。在.NET中，所有的类都继承自System.Object类，是一种引用类型，也就是说，当我们new出一个类的实例时，对象保存了该实例实际数据的引用地址，而对象的值保存在托管堆中。

struct(结构)是一种值类型，用于将一组相关的信息变量组织成为一个单一的变量实体。所有的结构都继承自System.ValueType类，是一种值类型，我们可以像使用int和char一样去使用struct。struct实例分配在线程的堆栈上，它本身存储了值，而不是指向该值的指针。

了解了class和struct的本质，我们可以通过分析和实验来总结二者的区别：

（1）关于实质：class是引用类型，struct是值类型

（2）关于职能：class是行为的封装，用来表述对象，而struct是数据的封装，用来储存数据

（3）关于继承：class支持继承自类和接口；而struct只能支继承接口。struct不能从class继承，也不能作为class的基类。

（4）关于构造函数：class可以声明无参构造函数，可以声明析构函数；而struct只能声明带参数构造函数，且不能声明析构函数。

（5）关于实例化：class要使用new关键字；而struct可以不使用new关键字，struct在声明时就进行了初始化过程，所有的成员变量均默认为0或null。

（6）关于抽象：class可以实抽象类(abstract)，可以声明抽象函数；而struct不能。

（7）关于重载：class可以声明protected成员、virtual成员、sealed成员和override成员；而struct不可以，但是值得注意的是，struct可以重载System.Object的3个虚方法，Equals()、ToString()和GetHashTable()。

（8）关于比较：两个class的比较有Equals和==两种，即值相等和引用相同；而两个struct可以直接通过==来判断。

（9）关于销毁：class实例由垃圾回收机制来保证内存的回收处理；而struct变量使用完后立即自动解除内存分配。

（10）关于参数传递：class变量是以按址方式传递；而struct变量是以按值方式传递的。

既然class几乎可以完全替代struct来实现所有的功能，那么struct还有存在的必要吗？至少在以下情况下，我们应该考虑使用struct来代替class：

1. 实现一个用于存储数据的结构时，可以考虑struct。
2. 考虑与某些非托管代码通信的兼容性问题时，可以考虑struct。

原文：NET中class与struct的区别简析

P.S. 附一篇《C#中虚函数和抽象函数的区别》

1NF 第一范式

如果一个关系模式R的所有属性都是不可分的基本数据项，则R∈1NF。

也可表述为：数据库表中的字段都是单一属性的，不可再分。

比如“地址”属性应该拆分为“城市”、“区县”、“具体地址”便于使用。

2NF 第二范式

若关系模式R∈1NF，并且每一个非主属性都完全函数依赖于R的码（多个主属性字段的组合），则R∈2NF

也可表述为：数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖（部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况），也即所有非关键字段都完全依赖于任意一组候选关键字。

比如选课关系表(学号, 姓名, 年龄, 课程名称, 成绩, 学分)，码为组合关键字(学号, 课程名称)，因为存在如下决定关系：

这个数据库表不满足第二范式，因为存在如下决定关系：(课程名称) → (学分) 和 (学号) → (姓名, 年龄)，即存在码中的部分字段决定非关键字的情况，所以不符合2NF。应修改为一以下三个表：

学生：Student(学号, 姓名, 年龄)；

课程：Course(课程名称, 学分)；

选课关系：SelectCourse(学号, 课程名称, 成绩)。

3NF 第三范式

关系模式R<U，F> 中若不存在这样的码X、属性组Y及非主属性Z（Z  Y）, 使得X→Y，Y→Z，成立，则称R<U，F> ∈ 3NF。

也可表述为：在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖，指的是如果存在”A → B → C”的决定关系，则C传递函数依赖于A。因此，满足第三范式的数据库表应该不存在如下依赖关系：关键字段 → 非关键字段x → 非关键字段y

比如：学生关系表为Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话)关键字段为“学号”，存在以下决定关系(学号) → (姓名, 年龄, 所在学院, 学院地点, 学院电话)，符合2NF；但存在(学号) → (所在学院) → (学院地点, 学院电话)，不符合3NF。应改为：

学生：(学号, 姓名, 年龄, 所在学院)；

学院：(学院, 地点, 电话)。

BCNF 鲍依斯-科得范式

设关系模式R<U，F>∈1NF，如果对于R的每个函数依赖X→Y，若Y不属于X，则X必含有候选码，那么R∈BCNF。

也可表述为：在第三范式的基础上，数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合第三范式。

比如：仓库管理关系表为(仓库ID, 存储物品ID, 管理员ID, 数量)，且有一个管理员只在一个仓库工作；一个仓库可以存储多种物品。这个数据库表中存在如下决定关系：

　　(仓库ID, 存储物品ID) →(管理员ID, 数量)

　　(管理员ID, 存储物品ID) → (仓库ID, 数量)

所以，(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是表的候选关键字，表中的唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下决定关系：

　　(仓库ID) → (管理员ID)

　　(管理员ID) → (仓库ID)

即存在关键字段决定关键字段的情况，所以其不符合BCNF范式。数据表应修改为：

　　仓库管理：(仓库ID, 管理员ID)；

　　仓库：(仓库ID, 存储物品ID, 数量)。

四种范氏之间的关系

每一个范氏都是进一步约束的关系，如下图：

四种范式之间的关系

参考：

1. 数据库范式（1NF 2NF 3NF BCNF）详解一
2. 数据库范式（1NF 2NF 3NF BCNF）详解二
3. SQL范式
4. 细说数据库范式

有一个例外是：在相同根域、相同协议、相同端口的情况下，可以利用设置document.domain方式来解决不同子域的跨站访问问题。

举个例子，想在witmax.cn中，访问www.witmax.cn域名下的内容，需要以下几步来完成：

1. 在主页面（位于witmax.cn中）通过隐藏的iframe嵌套子页面（内容位于www.witmax.cn）
2. 在主页面中设置document.domain=”witmax.cn”;
3. 在子页面中设置document.domain=”witmax.cn”;
4. 在主页面和子页面中可以相互访问内容了；需要跨域访问其他内容，可以通过在对应页面上发请求完成取回数据然后进行对应操作

P.S. 补充几点：

1、document.domain可以由子域www.witmax.cn修改为主域witmax.cn，而不能由witmax.cn修改为www.witmax.cn（不是所有浏览器都支持）。

2、不同根域、或不同协议、或不同端口之间的跨域访问只能通过服务器断的代理程序来解决了。

3、详细的示例见参考文档：

• 用document.domain解决Ajax跨子域
• 用document.domain+iframe实现Ajax跨子域
• 设置 iframe document.domain杂谈

工具功能：

• 统计攻防汇总数据
• 统计攻防用到的装备、服饰、交通物品
• 保存统计结果为文件

工具效果截图：

统计结果截图

工具用法：

1. 在IE或IE内核的浏览器中登陆开心网
2. 使用同一浏览器打开统计工具的网页文件，点击统计
3. 点击保存结果可将统计结果保存为文件

工具下载：

点击开心网X世界攻防物品统计工具

伯斯塔尔法则（Postel’s Law）设计原理：

发送时要保守；接收时要开放.

 发送给浏览器的数据尽量格式严谨；而浏览器接受数据时尽量做到容错，保持开放。

HTML5设计原理

HTML5由W3C HTML5工作组与WHATWG工作组（Web Hypertext Applications Technology Working Group）同心协力共同完成，在合作过程中遵循以下设计原理：

• 避免不必要的复杂性：简化代码输入和记忆
• 支持已有的内容：考虑到浏览器厂商实现功能时需要向下兼容
• 解决现实的问题：如允许将把段落中的文本放在链接里
• 求真务实
• 平稳退化：渐进增强
• 最终用户优先：一旦遇到冲突，最终用户优先，其次是作者，其次是实现者，其次标准制定者，最后才是理论上的完满

参考了一些经典的设计原理

Drupal界面的设计原理：

• 简化最常见的任务，让不常见的任务不至于太麻烦。
• 只为80%设计。
• 给内容创建者最大的权利。
• 默认设置智能化。

微格式设计原理：

首先为人类设计，其次为机器设计。

Mozilla的设计原理：

Internet作为一种公共资源，其运作效率取决于互通性（协议、数据格式、内容）、变革及全球范围内的协作。
基于透明社区的流程有助于增进协作、义务和信任。

Web设计原理：

大多数人的意见和运行的代码。

原文：HTML5设计原理