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

[Siam1205]

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.

[cheenamalhotra]

Hi @Siam1205

Are you using msbuild /target:publish to publish the same or some other tool?
Could you try using msbuild if not already and let us know if that works?

If not, please provide us a repro version of your ClickOnce application for us to investigate targets.

[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:
   

[Siam1205]

Thank you very much for your Quick reply. I am currently on vacation ehich is the reason for my bad response time.

According to your question: I am using the ClickOnce publish mechanism right from VS (I guess VS2017). Since I am on vacation I cannot try what you suggested right now. However:

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:
   

This exactly depicts the issue. Thank you very much.

[Siam1205]

I am currently using a workaround by adding both directories as content to the WPF App. This way, they are deployed along with the application. This works but is not ideal.

[cfaagaard]

I am currently using a workaround by adding both directories as content to the WPF App. This way, they are deployed along with the application. This works but is not ideal.

So do we right now :-)

[cheenamalhotra]

Thanks for the repro @cfaagaard and @Siam1205

I was able to reproduce the problem and saw that the SNI files were copied to Publish directory instead of deployment folder. The support for Publish Dir is for Dotnet SDK applications but there is no internal deployment folder so this was not covered.

I was able to resolve this by adding below target to csproj:

  <Target Name="_CopySNIFilesToPublishFolder" AfterTargets="_CopyFilesToPublishFolder" 
            Condition="'$(CopySNIFiles)' != 'false' And
                      '$(_CopySNIFilesToPublishFolder)' != 'false' And
                      '$(_DeploymentApplicationDir)' != '' And
                      HasTrailingSlash('$(_DeploymentApplicationDir)') And
                      Exists('$(_DeploymentApplicationDir)')"
            Inputs="@(SNIFiles)"
            Outputs="@(SNIFiles -> '$(_DeploymentApplicationDir)%(RecursiveDir)%(Filename)%(Extension)')">
    <Copy SourceFiles="@(SNIFiles)"
          DestinationFiles="@(SNIFiles -> '$(_DeploymentApplicationDir)%(RecursiveDir)%(Filename)%(Extension)')" />
  </Target>

Below is the output:

Let me know if you can get it working too, and we will plan to address this change in next SNI version.

[cfaagaard]

I can confirm it copies the directories and the dlls and pdbs…… and it gives a warning: "Warning: Publishing file 'SNI.pdb' that may contain sensitive or proprietary information."

In a clickonce-publish-scenario it should be sni.dll.deploy and no pdb published.

[cheenamalhotra]

In a clickonce-publish-scenario it should be sni.dll.deploy and no pdb published.

I agree. I think it should apply to all "Publish" targets as symbols are not needed during publish.
I've handled that internally and will be taken care of.

[Siam1205]

I will try the workaround you provided, @cheenamalhotra once I get back to work next Monday. However, according to @cfaagaard it actually works. I guess there is no need for me to additionally verify it.

If I understand you correctly, with SqlClient v2.0.0, your <Target> workaround won't be necessary anymore?

[cheenamalhotra]

Yes, the above target (with handled pdb case) will be part of M.D.S.SNI.targets in next release.

[Siam1205]

  <Target Name="_CopySNIFilesToPublishFolder" AfterTargets="_CopyFilesToPublishFolder" 
            Condition="'$(CopySNIFiles)' != 'false' And
                      '$(_CopySNIFilesToPublishFolder)' != 'false' And
                      '$(_DeploymentApplicationDir)' != '' And
                      HasTrailingSlash('$(_DeploymentApplicationDir)') And
                      Exists('$(_DeploymentApplicationDir)')"
            Inputs="@(SNIFiles)"
            Outputs="@(SNIFiles -> '$(_DeploymentApplicationDir)%(RecursiveDir)%(Filename)%(Extension)')">
    <Copy SourceFiles="@(SNIFiles)"
          DestinationFiles="@(SNIFiles -> '$(_DeploymentApplicationDir)%(RecursiveDir)%(Filename)%(Extension)')" />
  </Target>

I can also confirm that this workaround solves the issue. I will use that until it becomes obsolete. Thank you very much for your efforts.

[Siam1205]

Hello,

I must add the fact that the provided workaround indeed copies the files as expected. However: While installing the latest version of the application, it does not seem to copy the files to where the whole application is deployed locally hence the workaround does not work for ClickOnce applications that are installed locally upon starting the setup.exe or the .application file in the output directory.