lscorcia / sqlclient.snishadowcopy Goto Github PK

In case someone is interested, I've found another solution.

Use P/Invoke to SetDllDirectory:

[DllImport(@"kernel32.dll", CharSet = CharSet.Auto, SetLastError = true)]
private static extern bool SetDllDirectory(string lpPathName);

(See also this MSDN article about DLL load order)

Then, early in my Global.asax.cs Application_Start method (before any DB calls), call it like this:

SetDllDirectory(Server.MapPath(@"~/bin"))

After that, everything works as expected.

I still to consider this to be kind of a hack/workaround, but at least, it is working now in my scenario.

As I do understand, you can call SetDllDirectory multiple times to add additional directories (i.e. not overwrite the existing one).

So in case someone reading this might have other assemblies that refer to native DLLs in "x86" or "x64" folders, one might do something like this:

var bitness = Environment.Is64BitProcess ? @"x64" : @"x86";
SetDllDirectory(Server.MapPath($@"~/bin/{bitness}"));

I've also tried serving my test application from a local path (like "C:\Inetpub\wwwroot") and here, the error does not occur, even when not calling SetDllDirectory.

I'm still not sure why the error occurs for UNC paths only, and not for local paths, as I would expect that the shadow copied managed assemblies to fail the DllImports, too.

(I've also posted the above in this GitHub issue and this Stack Overflow post)

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.