Fix #785: support C# compile and SQLCLR assemblies in SDK-style Micro…

[allancascante]

Fix #785 — SDK-style Microsoft.Build.Sql supports SQLCLR (C# <Compile> items + SqlClrAssembly) on .NET Core and .NET Framework

Problem

Microsoft.Build.Sql SDK-style projects could not compile C# sources or register a SQLCLR assembly into the produced dacpac on the .NET Core build path (dotnet build). The SDK's Sdk.props and Sdk.targets aggressively suppressed BCL implicit references, C# language targets, and reference-assembly resolution because vanilla sqlproj builds don't need them — but those suppressions also blocked the Roslyn pipeline that SQLCLR requires. Symptoms: CS0518: Predefined type 'System.Object' is not defined, no CoreCompile, and SqlBuildTask never seeing a CLR assembly to put in the model.

Fix

In src/Microsoft.Build.Sql/sdk/Sdk.targets, when running under the .NET Core SDK (NetCoreBuild=true):

1. Re-enable BCL implicit framework references before the Microsoft.NET.Sdk import (DisableImplicitFrameworkReferences=false, AutomaticallyUseReferenceAssemblyPackages=true, NoStdLib=false).
2. Allow Microsoft.Data.Tools.Schema.SqlTasks.targets to import the real C# language targets (LanguageTargetsImported=false) so CoreCompile resolves.
3. New AddSqlClrReferencePath target injects tools/net8.0/*.dll (including the netstandard Microsoft.SqlServer.Server.dll) into the compile reference path.
4. New RewireImplicitDllForSqlClr target repoints IntermediateTargetFullFileName to the compiled CLR .dll so SqlBuildTask registers a SqlClrAssembly in the model.
5. Removed the SDK-level <Reference Remove="mscorlib" /> and the empty GetFrameworkPaths / GetReferenceAssemblyPaths overrides — they were silently no-oping RAR and breaking SQLCLR ref resolution.

A small build-time shim (src/Microsoft.Build.Sql/sdk/SqlClrShim.cs) supplies the Microsoft.SqlServer.Server.* types (SqlProcedureAttribute, SqlTriggerAttribute, SqlContext, SqlPipe, SqlTriggerContext) that exist in System.Data.dll on net472 but are absent from the netstandard build of Microsoft.SqlServer.Server shipped under tools/net8.0/. The shim is auto-included only when the consumer project has <Compile> items, so non-SQLCLR sqlproj projects are unaffected.

The shim and reference-path injection are also exercised on net472 via the .NET CLI path (where NetCoreBuild=true regardless of TargetFramework), enabling SDK-style SQLCLR builds for both TFMs.

Tests

Added two tests:

• SuccessfulSqlClrBuildOnNetCore (net8.0)
• SuccessfulSqlClrBuild (net472)

Both build a sample sqlproj containing a stored-procedure C# source and assert that at least one Assembly object is present in the produced dacpac model. They are currently gated with [Ignore] referencing #785 because the runtime piece lives in a DacFx product change (SqlBuildTask / AssemblyParser) that has not shipped publicly yet. Re-enable by removing [Ignore] once DacFxPackageVersion in Directory.Packages.props advances to the first release containing the fix.

Validation

Cross-repo loop used during development:

1. Built a private DacFx drop (Microsoft.SqlServer.DacFx.170.5.0-pr2143342.2.nupkg) from the in-flight DacFx PR.
2. Local NuGet.config (not committed) pointed at the private feed.
3. Built the SDK with the version override:

   dotnet build src\Microsoft.Build.Sql\Microsoft.Build.Sql.csproj -c Debug -p:DacFxPackageVersion=170.5.0-pr2143342.2