在 SQL 服务器数据库项目构建期间使用了错误的编译器

Usage of wrong compiler during SQL Server Database Project building

我在使用 Visual Studio 2015 编译 SSDT SQL 服务器数据库项目时遇到问题。我想在我的数据库项目中使用 C# 6 功能,但它似乎不受支持。 比如我在我的db项目中添加了下一个class:

namespace Database1
{
    class ClassFile1
    {
        public string Str { get; } = string.Empty;
    }
}

我试过编译这个,但是我得到了错误:

CS1519:class、结构或接口成员声明中的无效标记“=”

我发现这个错误的原因是 VS 2015 使用的编译器版本错误。下一行编译由 VS 生成:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Csc.exe /noconfig /nowarn:1701,1702,2008 /nostdlib+ /errorreport:prompt /warn:4 /define:DEBUG;TRACE /errorendlocation /preferreduilang:en-US /highentropyva+ /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6\mscorlib.dll" /debug+ /debug:full /optimize- /out:obj\Debug\Database2.dll /subsystemversion:6.00 /target:library /warnaserror- /utf8output ClassFile1.cs 

可以看到,用的是C:\Windows\Microsoft.NET\Framework\v4.0.30319\Csc.exe,是错误的。

我已经尝试从 VS 2015 的开发人员命令提示符编译数据库项目并且成功完成,因为在此提示符中 csc.exe 是 Roslyn 编译器 (C:\Program Files (x86)\MSBuild .0\Bin\csc.exe) 支持 C# 6 功能。您可以查看问题

我尝试使用 MSBuild 14.0 编译项目,也成功了。

问题是:我如何 change/override 我的 VS 用于从旧 C 编译 SSDT DB 项目的编译器版本:\Windows\Microsoft.NET\Framework\v4.0.30319\Csc.exe 到新的 Roslyn 编译器 (C:\Program Files (x86)\MSBuild.0\Bin\csc.exe)?

您需要将要部署到的 SQL 版本使用的 clr 版本作为目标:

SQL 2005-2008 R2 = CLR 2

SQL 2012 = CLR 4

恐怕你不能 运行 机器上的任何版本的 clr。

编辑

我也在尝试这样做,但遇到了同样的问题。我的解决方法是创建一个单独的常规 class 库项目。我将 C# 代码从我的数据库项目移到了新库中(它将在 VS 2015 中使用 C# 6/Roslyn 进行编译)。然后从我的数据库项目中引用这个 class 库。

请记住设置对 class 库的引用的属性:Model Aware=true 和 Generate Sql Script=true。我还没有对此进行彻底测试,但我能够使用发布命令从我的数据库项目中部署它,并调用 class 库中的函数。

好消息!
Visual Studio 2017 将对 SSDT 数据库项目使用当前的 C# 编译器,因此
的所有功能 C# 6 最终将在 SQL 服务器程序集中工作。

使用的编译器路径为:

C:\Program Files (x86)\Microsoft Visual Studio17\Enterprise\MSBuild.0\Bin\csc.exe

因为所有 C# 6 功能都只是纯粹的编译器功能,如果您只针对 .NET 3.5 和 SQL Server 2008,您现在甚至可以使用它们。

在 Visual Studio 2017 RC 中,我还能够使用一些 C# 7 功能,例如表达式主体构造函数、新的 out 变量、ref returns、增强的 switch/is 模式匹配和改进的 binary/hex 文字。但是我无法使用本地函数或任何与元组相关的东西,比如新的元组 return 类型、元组文字或新的解构声明。
也许这种行为会在 Visual Studio 2017 的最终版本中改变。