Microsoft.Data.SqlClient.SNI not deployed along with ClickOnce

Describe the bug

The nuget package Microsoft.EntityFrameworkCore.SqlServer v3.1.2 needs the reference to Microsoft.Data.SqlClient.SNI v1.1.1. The SNI package is automatically added to the project when referencing the SqlServer v3.1.2 which is expected. When building the solution, the directories x64 and x86 are created as expected and everything works fine when started from the \bin\debug and \bin\release folders.

To reproduce the issue

When deploying the solution using ClickOnce, both directories (x86 and x64) are not included so that the application does not work anymore as it lacks the SNI.dll reference. I cannot see a way to solve the issue since I cannot include the reference under

ProjectName > Publish > Application Files...

I saw this (fixed) issue but for ClickOnce, it does not seem to be fixed.

Expected behavior

When deploying the application using ClickOnce, the x64 and x86 directories including the native SNI.dll libraries are copied to the respective version directory inside the “Application Files” directory and referenced properly.

[jeremy-waguet]

For those who encountered the same issue I have, I stored SNI.dll to publishing directory and I check if it exists at each application start. If it doesn’t exist I download them to the application directory. That sounds to be the UGLIEST HACK I ever done ! Hope to drop that code very soon. Here is my sample code for reference this has to be before any connection to database so in main static method it’s okay @Siam1205 :

/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
private static void Main()
{
    // HACK : Download SNI.dll manualy waiting that should be deployed as part of the 'Microsoft.Data.SqlClient.SNI' package by clickonce but is NOT deployed due to bug here : https://github.com/dotnet/SqlClient/issues/441
    string applicationDirectoryPath = Path.GetDirectoryName(Application.ExecutablePath);
    string x86SNIDirectoryPath = Path.Combine(applicationDirectoryPath, "x86");
    if (!Directory.Exists(x86SNIDirectoryPath))
    {
        Directory.CreateDirectory(x86SNIDirectoryPath);
        using (WebClient client = new WebClient())
        {
            client.DownloadFile("https://clickoncedeploydomain.tld/ClickOnceDeployDirectory/x86/SNI.dll.deploy", Path.Combine(x86SNIDirectoryPath, "SNI.dll"));
        }
    }
    string x64SNIDirectoryPath = Path.Combine(applicationDirectoryPath, "x64");
    if (!Directory.Exists(x64SNIDirectoryPath))
    {
        Directory.CreateDirectory(x64SNIDirectoryPath);
        using (WebClient client = new WebClient())
        {
            client.DownloadFile("https://clickoncedeploydomain.tld/ClickOnceDeployDirectory/x64/SNI.dll.deploy", Path.Combine(x64SNIDirectoryPath, "SNI.dll"));
        }
    }
    ...
}

[cfaagaard]

We are experiencing the same bug. To reproduce:

1. Create new wfp app (.net 4.7.2)
2. Add nuget “Microsoft.EntityFrameworkCore” (version 3.1.2)
3. Add nuget “Microsoft.EntityFrameworkCore.SqlServer” (version 3.1.2)
4. Build project (debug or release) Check bin/debug folder. It contains the two folders x64 and x86 with the SNI.dll in each folder. If you publish same project (using visual studio 2019 (16.4.5)) the published folder looks like this: