SniLoader doesn't always find the current shadow copy folder

[abasau-incomm]

The root cause of the issue is that IIS doesn't always clean up shadow copy folders with Microsoft.Data.SqlClient.DLL when a new version of web app is deployed.

E.g. IIS copies Microsoft.Data.SqlClient.DLL into C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\<app_name>\a782057e\5e070cea\assembly\dl3\747cbe86\00116ed2_b55cd701\Microsoft.Data.SqlClient.DLL during the first deployment. When the next deployment happens and IIS put Microsoft.Data.SqlClient.DLL into C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\<app_name>\a782057e\5e070cea\assembly\dl3\747cbe86\0055c85d_f61dd801\Microsoft.Data.SqlClient.DLL, the code below will find all folders with Microsoft.Data.SqlClient.DLL in them and, if the old folder is the first in the list, it will see that Microsoft.Data.SqlClient.SNI.x64.dll already exists there and will exit without copying the file. This is because 00116ed2_b55cd701 precedes 0055c85d_f61dd801 in the list. As a result, Microsoft.Data.SqlClient.DLL loads Microsoft.Data.SqlClient.SNI.x64.dll from the web app folder and IIS locks the file.

var sqlClientShadowAssembly = Directory.GetFiles(
    currentShadowPath, "Microsoft.Data.SqlClient.dll",
    SearchOption.AllDirectories).FirstOrDefault();

I had to modify that code to find the most recent shadow copy folder like this.

var sqlClientShadowAssembly = Directory.GetFiles(currentShadowPath, "Microsoft.Data.SqlClient.dll", SearchOption.AllDirectories)
    .OrderByDescending(filePath => new FileInfo(filePath).CreationTimeUtc)
    .FirstOrDefault();

This issue didn't reproduce on my development machine but it was reproducing in prod-like environment quite often.