fix #12445 by migrating dotnet-sql-cache to new SqlClient

[analogrelay]

Tested by

1. Created a new DB
2. Created a schema "TestSchema" (just to test a non-default schema)
3. Ran

dotnet ..\..\artifacts\bin\dotnet-sql-cache\Debug\netcoreapp3.0\dotnet-sql-cache.dll create "Data Source=(localdb)\MSSQLLocalDB;Initial Catalog=SqlCacheTest;Integrated Security=True;Connect Timeout=30;Encrypt=False;TrustServerCertificate=False;ApplicationIntent=ReadWrite;MultiSubnetFailover=False" "TestSchema" "TestTable"

1. Dumped the schema for the new TestSchema.TestTable table:

CREATE TABLE [TestSchema].[TestTable] (
    [Id]                         NVARCHAR (449)     COLLATE SQL_Latin1_General_CP1_CS_AS NOT NULL,
    [Value]                      VARBINARY (MAX)    NOT NULL,
    [ExpiresAtTime]              DATETIMEOFFSET (7) NOT NULL,
    [SlidingExpirationInSeconds] BIGINT             NULL,
    [AbsoluteExpiration]         DATETIMEOFFSET (7) NULL,
    PRIMARY KEY CLUSTERED ([Id] ASC)
);


GO
CREATE NONCLUSTERED INDEX [Index_ExpiresAtTime]
    ON [TestSchema].[TestTable]([ExpiresAtTime] ASC);

[analogrelay]

I'm 95% sure this tool isn't included by the CLI (it's not present in the [DOTNET_HOME]\sdk\[version]\DotNetTools directory) but I would love @livarcocc (or someone on the cli team) to confirm that I'm correct there.

[livarcocc]

@anurse it was removed back in May: dotnet/installer#2014.

[analogrelay]

Cool, thanks for confirming @livarcocc . That was my understanding as well but didn't have the context top-of-mind.

[dougbu]

Test failures look suspicious. @rynowak @pranavkm @ajaybhargavb did something bad sneak into 'master'?

[analogrelay]

@dougbu What test failures? I only see already-quarantined tests failing. The build failure was a code signing failure, which does appear to be related, though I'm not sure how to resolve it right now (will look in to it).

F:\workspace\_work\1\s\.packages\microsoft.dotnet.arcade.sdk\1.0.0-beta.19365.4\tools\Sign.proj(81,5): error : Could not determine certificate name for signable file(s):
F:\workspace\_work\1\s\.packages\microsoft.dotnet.arcade.sdk\1.0.0-beta.19365.4\tools\Sign.proj(81,5): error : 	File: F:\workspace\_work\1\s\artifacts\tmp\Release\ContainerSigning\892\tools/netcoreapp3.0/any/Microsoft.Data.SqlClient.dll
  SignToolTask execution finished.

[dougbu]

@anurse yeah, the test failures were all flaky tests, including those @javiercn and / or @rynowak are working on. I missed the real build failure ☹️

[analogrelay]

I believe I've resolved the signing issue.

[analogrelay]

Do we still validate that the assembly is signed, even when we label it as not to be signed by us? Since this DLL comes from a different team, they handle the signing, but I would like us to be validating that it's all signed (in case they miss signing sometime).

For additional context: We're using the OOB SqlClient in dotnet-sql-client which has to embed all it's dependencies (since it's a global tool). Hence this DLL now appears in the dotnet-sql-client nupkg. We don't ship this tool in the SDK nor in any shared framework.

[analogrelay]

cc @aspnet/build

[dougbu]

As far as I can tell, we do not do signing validation in this repo at the moment. That'll be corrected as I complete #11924 because the new stages include signing validation.

FYI everywhere else, we use the generic release pipeline (https://dnceng.visualstudio.com/internal/_release?view=mine&definitionId=39 aka "Public Dev. Release") which does signing validation for everything it publishes.

[analogrelay]

Doing validation on publish is a reasonable stop-gap until #11924 goes in, thanks!

[analogrelay]

I don't anticipate a problem, just being paranoid ;)