sql-server - Visual Studio 2013 CLR存储过程

Question

我一直在使用Visual Studio（VS2008）的早期版本以及SQL Server 2008。

最近，我的组织搬到了VS2013和SQL Server2012。我发现VS2013中的数据库接口与VS2008中存在的数据库接口有很大不同。

我的问题基本上是，是否有人知道或引用了详细说明如何执行此处描述的操作的文章：

http://yassershaikh.com/how-to-create-a-clr-stored-procedure-using-c-and-visual-studio/

（特别是将DLL部署到SQL Server 2012数据库）。

但是使用VS2013和SQL Server 2012。

Answer 1

（如果此处的信息与您看到的信息之间存在细微差别，我将在Windows 8上运行带有SSDT 11.1.31203.1的Visual Studio 2012 Update 4）

在VS 2008 / VS 2010中，您可以“部署”数据库项目（分别为.csproj / .dbproj文件），以将程序集和T-SQL包装对象放入SQL Server。 Visual Studio的较新版本在“生成”菜单中仍具有“部署”选项（至少VS 2012在解决方案和项目中都包含了这些选项），但是它们什么也不做。现在，您有了一个.sqlproj文件，将解决方案/项目输入数据库的方法是使用“构建”菜单中的“发布{SolutionName} ...”选项。

稍后会有更多关于发布的信息。首先，以下信息可能会有所帮助：

SQL Server / SSDT


SQL Server项目（即.sqlproj）通过SQL Server Data Tools（SSDT）显式处理
默认情况下，Visual Studio / SSDT指向本地SQL Server数据库。首选使用的是SQL Server Express Edition（另请参见SQL Server Express User Instances），但是从SQL Server 2012开始，Express Edition有了一个新版本，称为“ Express Edition LocalDB”（通常简称为“ LocalDB”）。


Introducing LocalDB, an improved SQL Express
Local Data Overview（SQL Server Express与LocalDB）
SQL Server Express LocalDB
How to: Upgrade to LocalDB or Continue with SQL Server Express

SQL Server Express LocalDB实例位于以下路径中：
C:\Users\{User Name}\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances\{Instance Name}
您使用以下约定连接到LocalDB：
(localdb)\{Instance Name}
创建新解决方案时，将在以下位置创建一个文件夹，用于存放每个项目的数据库文件：
C:\Users\{User Name}\AppData\Local\Microsoft\VisualStudio\SSDT\{Solution Name}
在每个项目中，该...\SSDT\{Solution Name}文件夹中至少将包含两个文件：


{Project Name}.mdf
{Project Name}.ldf

如果您向该解决方案添加更多项目，则新文件将出现在该...\SSDT\{Solution Name}文件夹中
不管您是否使用它们，都会在初始创建新项目时创建solution文件夹和per-project-database文件；-)


视觉工作室


“项目属性”中有3个主要选项卡，它们将控制编写脚本的内容以及可能发布的内容
项目设定


在“输出类型”下，“创建脚本（.sql文件）”复选框控制Build操作是否创建SQL脚本以至少使用Assembly删除并重新创建DB：
{Build Output Path}\{Build Output File Name}_Create.sql

SQL CLR


“生成DDL”复选框可控制是否创建T-SQL包装器对象：
CREATE {Object Type} {Object Name} ... AS EXTERNAL NAME {Assembly Name}.{Class Name}.{Method Name OR "name" property, if specified, in the [SqlProcedure] / [SqlFunction] / [SqlUserDefinedAggregate] / [SqlUserDefinedType] / [SqlTrigger] attribute}
“包括符号”复选框控制是否将{Assembly Name}.pdb文件导入到SQL Server（在sys.assembly_files中）；即使未选中此选项，也会在.pdb中创建{Build Output Path}文件。

建立


这些不是特定于SQLCLR的
“生成输出路径：”控制最终的DLL，PDB，SQL和DACPAC文件的位置
“生成输出文件名：”控制SQL脚本和DACPAC文件的名称

部署选项卡已被删除


此选项卡上有一个“部署代码”复选框，其中包括.pdb文件和源代码（.cs和/或.vb.）文件作为ALTER ASSEMBLY {Assembly Name} ADD FILE FROM 0x... AS {File Name}条目。该选项似乎已由SQL CLR选项卡上的“包含符号”复选框取代，该复选框仅包含.pdb文件，而不包含源代码文件。 [[我认为这是一种改进，因为我从未喜欢过部署源代码的想法，因为某些人（也许很多？）将所有这些东西都推广到了Production :-(。]



在“构建”菜单中选择“发布{解决方案名称} ...”选项将弹出“发布数据库”对话框，询问数据库详细信息。对于“目标数据库连接：”，单击右侧的“编辑...”按钮。将打开“连接属性”对话框。将出现“服务器名称：”的下拉列表，您可以下拉列表以发现实例，也可以只键入名称。如果您有在本地运行的默认实例，则应该只需键入“（local）”（但不要使用双引号）。下一节“登录到服务器”中的默认身份验证为“使用Windows身份验证”。如果使用SQL Server登录名，则可以选择另一个单选按钮，然后输入“用户名：”和“密码：”详细信息。下一部分是“连接到数据库”，并且上面的“选择或输入数据库名称：”单选按钮已被选中。如果下拉列表，则有一个下拉列表，其中将填充在“服务器名称：”下拉列表中选择（或输入）的服务器上的数据库列表。选择或输入所需的数据库，然后单击对话框左下方的“测试连接”按钮。您应该看到一个弹出窗口，指出“测试连接成功”，因此请单击该弹出窗口中的“确定”按钮，然后单击“连接属性”对话框中的“确定”按钮。

现在你可以：


单击“将配置文件另存为...”按钮（在“发布数据库”对话框的左下方）
下次，只需单击“加载配置文件...”按钮（它将具有可见的设置以及“高级...”按钮中配置的任何内容）
点击


“发布”按钮立即推送到数据库
“生成脚本”按钮可以简单地创建发布SQL脚本：
{Build Output Path}\{Build Output File Name}.publish.sql

您还可以部署DACPAC文件：Data-tier Applications


仅供参考：可在以下位置找到用于创建对象的基本T-SQL片段，但您应注意不要按原样运行SQL脚本，因为这些项目的顺序不是可运行的：
{ProjectDir}\obj\{Configuration Name}\{Assembly Name}.generated.sql

对于上面的某些特定于Visual Studio的引用，这些是您在UI中看到的字段的名称。在.sqlproj文件中的等效项是：


{项目名称} == <Name>
{程序集名称} == <AssemblyName>
{Build Output Path} == <OutputPath>
{Build Output File Name} == <SqlTargetName>
“创建脚本（.sql文件）”复选框== <GenerateCreateScript>
“生成DDL”复选框== <GenerateSqlClrDdl>
“包含符号”复选框== <GenerateSqlClrSymbols>


通常，有关SQLCLR的更多信息，我在SQL Server Central上写了一个名为“ Stairway to SQLCLR”的系列（需要免费注册）。 （目前，最终只有约12篇文章发表了4篇文章。巧合的是，下一篇是关于Development＆Visual Studio的：-））

编辑：
一项有趣的且通常是很好的新功能是对依赖项的验证，以提供T-SQL对象的编译时错误，就像.Net语言一样。不利的一面是似乎没有办法禁用它。除基于CLR的触发器外，这通常不会影响SQL CLR项目。这里的问题是，如果启用了“生成DDL”选项，则要执行“构建”，需要填写Target属性的Event和SqlTrigger属性。并且，模型（即数据库模型）验证步骤将检查以确保Target属性中命名的表确实存在。如果没有，您将得到一个unresolved reference to object错误。看来，传递此消息的唯一方法是：a）在您的项目中拥有该对象，或b）在被称为“数据库参考”的项目中拥有该对象：


如果只需要引用几张表，则最简单的方法是在SSMS中生成其CREATE TABLE语句，然后在解决方案资源管理器中右键单击项目（或转到“项目”菜单），然后转到到“导入->脚本（* .sql）...”。
如果您在许多不同的表上都有许多触发器，则可以：


在相同的解决方案中创建一个新项目：


在解决方案资源管理器中右键单击项目名称（或转到“项目”菜单）
转到“导入->”
选择“数据库...”
输入连接信息

将架构提取到.dacpac文件：


在VS中转到“ SQL Server对象资源管理器”
选择您的服务器并展开数据库列表
右键单击有问题的数据库
选择“提取数据层应用程序...”
选择一个位置，然后输入文件名（在“磁盘文件”字段中）。
点击“确定”按钮

无论选择哪种方法，都需要将其添加为“数据库参考”：


右键单击主项目中的“参考”文件夹（或转到“项目”菜单）
转到“添加数据库参考...”
根据您选择的方法，选择“当前解决方案中的数据库项目”或“数据层应用程序（.dacpac）”
选择新创建的项目或.dacpac文件
对于“数据库位置：”下拉列表，必须选择“相同数据库”！
点击“确定”按钮




记住：


如果要导入单个表，则可能还需要导入在要导入的任何表上的任何外键中引用的任何表
每次都会在CREATE TABLE脚本中生成完整的_Create DDL，但是“发布”脚本将仅包含用于更改的DDL，因此，如果表的定义中没有更改，则表DDL将不会出现在“发布” .sql脚本中。通过将项目或.dacpac文件中的表定义与“发布”对话框/向导的“连接设置”中定义的目标数据库进行比较来确定更改。