SNI.dll file locked when ASP.NET (Framework 4.8) App is running in IIS
See original GitHub issueDescribe the bug
The SNI.dll file is loaded/locked by IIS when using a Microsft.Data.SqlClient connection in a ASP.NET 4.8 Framework website but is not unloaded when the app is shutdown. Subsequent attempts to build or deploy the site are blocked by the error Unable to delete file “bin\x86\SNI.dll”. Access to the path ‘…\bin\x86\SNI.dll’ is denied. Every other dll in the bin folder can be deleted even while the web app is still running save for this one.
To reproduce
1.) Create an ASP.NET MVC website on the 4.8 Framework 2.) Add the Microsoft.Data.SqlClient package 3.) In the HomeController.Index method open a SqlConnection and execute an arbitrary command
using (var connection = new SqlConnection("<connection string here>"))
{
connection.Open();
new SqlCommand("SELECT 1", connection).ExecuteNonQuery();
}
4.) Cause the site to shutdown by modifying the web.config or stopping the debugger. 5.) The SNI.dll file remains locked and cannot be replaced or modified without shutting down IIS or the application pool associated with the website
Expected behavior
The SNI.dll should be unlocked (like the rest of the files in the bin folder) so that a site can be updated through deployment or build.
Further technical details
Microsoft.Data.SqlClient version: v1.1.0 .NET target: Framework 4.8 SQL Server version: SQL Azure Operating system: Windows 10 Professional / Windows Server 2016 Datacenter (Azure VM)
Issue Analytics
- State:
- Created 4 years ago
- Reactions:36
- Comments:82 (24 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
I get that it happens when apps are active or running in IIS. i’m not debating that. I understand that the designs are very different as well, i’m not debating that either. I’m just saying my use cases are not edge or unique, and even though i don’t have a solution to this issue, i don’t think it should be closed or ignored.
The 2 places i see this issue are:
I understand i’m in .net framework, and that is a purgatory that i should try to get myself out of, but the move to use microsoft.data.sqlclient was part of that move for me, but it’s actually making the move harder because of these issues. I have a large monolith .net framework app and i am gradually moving projects towards .net standard. This gradual move is what is causing my issue apparently.
So the solution is that i can’t move gradually? I have to move everything to .net core immediately, all in one go without doing things in steps? That just doesn’t seem realistic, which is the only point i’m trying to make here. This issue is making development more difficult, and the only solution seems to be to move everything BACK to .net framework so i can use System.Data.SQLClient instead, which prevents me from ever really moving to .net core.
.Net core is the primary focus. Great, totally down with that. Shouldn’t that mean that aiding users from migrating from .Net Framework to .Net core should be important then?
I’m surprised this issue is locked. while it might be ‘as it worked before’ with the previous version of sqlclient, it’s not really ideal behavior, right? recycling the app pool isn’t always reliable, and additionally I hit this issue frequently on my development box on just compiling.