发布于 2016-06-26 08:38:31 | 178 次阅读 | 评论: 0 | 来源: 网友投递

这里有新鲜出炉的精品教程，程序狗速度看过来！

ASP.NET

ASP.NET 是.NET FrameWork的一部分，是一项微软公司的技术，是一种使嵌入网页中的脚本可由因特网服务器执行的服务器端脚本技术，它可以在通过HTTP请求文档时再在Web服务器上动态创建它们。 指 Active Server Pages（动态服务器页面） ，运行于 IIS（Internet Information Server 服务，是Windows开发的Web服务器）之中的程序 。

---

如同交响乐一样，构造软件系统不一定必须某个强大的明星驱动，我们站在历代ADO.NET的肩膀上，更好地回归到SQL Server的核心开发：SQL Server LocalDB 在 ASP.NET中的应用

我相信世界总是会向更好的方向发展，今年的维也纳新年音乐会没有往年的明星级指挥，但是它通过回归奥地利的本质，以更传统的聚合法则，让过往的艺术家们一代代创造的灿烂，在新的指挥手中，迸发出更深邃的音节。在此，也祝大家新年快乐。
如同交响乐一样，构造软件系统不一定必须某个强大的明星驱动，我们站在历代ADO.NET的肩膀上，更好地回归到SQL Server的核心开发：SQL Server LocalDB 在 ASP.NET中的应用。

使用SQL Server LocalDB的优势：

快速部署完整的SQL Server。以后项目可以无缝升级到高级版本。 它是真正的SQL Server，直接使用到SQL Server 2012的所有功能。免费，对于初创企业和低配置服务器，可以节约前期的不少运营成本。
缺点与限制：

必须对服务器有完全控制权限，租用虚拟主机的用户无法使用（但是目前一个VPS和虚拟主机的价钱差别也不大）。无法通过bin文件夹中放置DLL进行绿色部署，服务器必须安装SQL Server Express LocalDB。

首先我们必须明白怎样管理数据库，在SQL Server 2012管理工具中：



使用 (LocalDb)\v11.0 字符串来连接到当前本机的 LocalDB运行时环境。

.net framework早于4.0.2的情况下，直接使用命名管道来连接 LocalDB，例如："Server=np:\\.\pipe\LOCALDB#F365A78E\tsql\query"

这一步与我们的开发环境设置关系不大，但是对于将来调试差错，有很大帮助。

下面通过两个步骤设置在ASP.NET中运行LocalDB：

1：解决数据库文件定位

使用连接字符串：connectionString="Data Source=(LocalDb)\v11.0; Initial Catalog=xxx;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|\test666.mdf"。





我们把系统生成的数据库文件，在管理工具中附加到SQL Server中，会看到程序自动创建了一个名为DBBases的表

以上几点解决了基本的连接功能，Visual Studio 2012 与SQL Server 2012 Management Studio中调试通过。

但是，问题只解决了一半， 注意上面我用的是“vs2012”、“调试”这两个词语，目前我还没说过在“IIS”中“运行”。

2：IIS中的用户权限问题

在visual studio 中调试项目，使用的是windows 本地用户进程，该进程具有比较高的权限（一般情况下与Administrator无异）。

而要在 IIS 中实际运行项目，执行程序时windows7、2008、2008R2、Server 2012默认都是使用ApplicationPoolIdentity进程。

ApplicationPoolIdentity进程的权限在本篇中不过多解释，在这里你只要把它理解为一个权限非常低的用户进程（IIS_IUSRS组）即可。就算LocalDB是再怎么精简的版本，它毕竟也是SQL Server，在最极端的情况下，需要经历“开启sqlserver.exe进程”、“创建数据库”两个步骤，不是ApplicationPoolIdentity进程（IIS_IUSRS组）想做就做的。

解决办法

1： 应用程序池 – 高级设置 – 标识， 以localsystem账户运行。Localsystem进程等同于本地administrator。



这样的解决办法最简单，直接通过localSystem账户运行进程，一切烦恼瞬间化为乌有。但是随之而来反面因素便是带来了潜在安全威胁： 如果一个不怀善意的客户端上传了一段恶意代码， 那么恶意代码一旦获得运行机会，那么将是以administrator的权限运行于服务器，这将意味着什么，不必多说。

2：通过AttachDBFile，挂接数据库文件到更高的SQL Server版本解决问题。

LocalDB是真正的SQL Server，可以直接和其它版本SQL Server 无缝兼容，我们只需要把数据库文件挂接到Express或更高版本SQL Server中，

仅仅是需要把：“Data Source=(LocalDb)\v11.0;”修改为: “Data Source=.\SQLExpress”，也可以解决一切烦恼了。这样的做法虽然具备实际意义，但是与本文的主题关系不大，在此也不多描述了。

最后，基于安全因素的运行建议：

1：直接使用localsystem运行整个程序，只要不允许客户端上传文件，整套程序可以放心运行。但是大多数情况下一个有意义的web程序都是允许客户端上传文件的，所以列举一个上传文件的解决办法：

在用户上传文件时，把文件放置到别的进程空间中，运行时，通过外链（upload.abc.com）文件的办法，达到了让用户文件运行于绝对安全的进程中。



2：与建议1相反，把涉及到数据库操作的代码封装为服务，通过WCF或Web API的自宿主功能，运行在另一个安全进程中（仅限本地连接），面向公众的Web程序通过本地服务接口调用之，如此可以把一切安全因素最小化。（但是开发过程与维护会增加更高的复杂度）