SqlClient: Package causes a new UWP app to fail Windows App Certification for Deployment to Microsoft Store

Hi @David-Engel

Thank you again for your suggestions. After further troubleshooting I was able to get it to successfully pass the Binary analyzer check on my local machine. I first had to add the following lines to my project’s post build script to delete all files recursively as you suggested: cd $(TargetDir) DEL /F/Q/S Microsoft.Data.SqlClient.SNI.dll

Similar to your suggestions about the *.deps.json file for a .NET Core project, I then also had to remove all references (about 50 in my case) to Microsoft.Data.SqlClient.SNI.dll in the project.assets.json file located in the obj folder of my UWP App project. Doing this right before publishing the app packages for the project I was able to get a package created which successfully passes the Binary analyzer check. It’s worth noting that a Rebuild All on the solution would trigger a NuGet Package Restore, which re inserts the ~50 references to the JSON file and then it will not pass or build successfully again until they are deleted.

For me what worked is using PowerShell script to remove Microsoft.Data.SqlClient.SNI references in project.assets.json from the obj directory after restore, before build. I am using build pipeline to create the store upload package so I needed something automated. The PowerShell script:

function Remove-Property {
  param(
    [Parameter(Mandatory, ValueFromPipeline, Position = 0)]
    [object] $InputObject,
    [Parameter(Mandatory, Position = 1)]
    [string] $NamePattern
  )
  process {
    foreach ($el in $InputObject) {
      foreach ($propName in $el.psobject.Properties.Name) {
        if ($propName -like $NamePattern) {
          $el.psobject.Properties.Remove($propName)
        }
        else {
          $null = Remove-Property -InputObject $el.$propName -NamePattern $NamePattern
        }
      }
    }
    $InputObject
  }
}

$fileContent = Get-Content ".\obj\project.assets.json" -Raw | ConvertFrom-Json
$fileContent = Remove-Property -InputObject $fileContent -NamePattern "*Microsoft.Data.SqlClient.SNI*"
$fileContent | ConvertTo-Json -Depth 100 | Out-File ".\obj\project.assets.json" -Force

In my case the obj and bin folders do not exist. Restore target is run using msbuild, then the script above is run from the UWP project folder. Then I run msbuild with appropriate parameters to create store upload package, and it passes certification.

The above script creates a world where Microsoft.Data.SqlClient package does not depend on SNI package, and it removes any references to the SNI package from targets/libraries portions of json file.

(sigh). Sad this was needed, but hope it helps someone.

Is there any chance that you can work with the Microsoft Store team and have them allow this Microsoft SNI dll?

@wjvii The purpose of UWP is to provide a uniform set of APIs that apps can use, which are supported on all the devices that Windows 10 runs on. The Microsoft.Data.SqlClient.SNI.dll is not compiled specifically to use only the UWP core APIs, so there isn’t any way the store can simply “allow” it because, without changing it, it likely would not work across all devices.

@bolyb As ErikEJ suggested, try deleting the SNI files from your build/publish folder (and maybe remove any references to it from your dep.json file, depending on your publish config), assuming you have set the switch to Enable Managed SNI on Windows. Those SNI dlls are not actually used when that switch is set.

Remove the SNI files during build?

@cheenamalhotra is there any chance that you can work with the Microsoft Store team and have them allow this Microsoft SNI dll?

Hi @bolyb @wjvii

I think the error you’re seeing is mainly due to SNI dependency that continues to exist even if you enable Managed SNI and do not use that DLL at all. I think the only solution that would work is when you we completely move away from Native SNI to managed for UAP targets. But because Microsoft.Data.SqlClient is now an external component and not built same way as System.Data.SqlClient was built in the .NET Core SDK, we have had challenges in the past when building for UAP targets.

I’ll reopen this issue again, and we can revisit options that we can do here.

@bolyb @cheenamalhotra @David-Engel I too am circling back around this as I have run into the same thing again as well, I updated #703 mentioned above back in December. Right now, we cannot ship the newest versions of our Microsoft Windows application due to this issue.

@bolyb One of the things that was done in System.Data.SqlClient was specifically supporting a UWP build target. In doing that, S.D.SqlClient could provide different bits for UWP targets versus regular Windows targets. The UWP-specific bits in S.D.SqlClient do not include references to the native sni.dll (it uses a managed SNI implementation which is not quite as performant). In creating Microsoft.Data.SqlClient, that UWP-specific build target was not done and thus UWP applications which reference M.D.SqlClient will get the Windows bits with the native sni.dll references. It is on the roadmap to provide a UWP-specific build target in M.D.SqlClient with similar changes, but there is no date set for it at this time.

I recommend staying with System.Data.SqlClient for UWP applications until UWP-specific build support is added to Microsoft.Data.SqlClient.

Hi @bolyb

I believe you’re suggesting changes in SNI.dll source which loads from runtime.native.System.Data.SqlClient.sni when targeting UWP Apps.

Currently there are some hiccups with this library, we’ll look into it if feasible and get back to you.