包含SQLite.Interop.dll的发布项目失败，因为它正由另一个进程使用

Question

We've recently added SQLite to an existing C# WebForms application running on IIS and we're now having problems publishing it from Visual Studio or Team City .

If we try to publish after a user has accessed a route that in turn accesses the SQLite DB we get the following error:

Unable to add 'bin/x86/SQLite.Interop.dll' to the Web site. Unable to add file 'bin\\x86\\SQLite.Interop.dll'. The process cannot access the file because it is being used by another process.

In order to minimize the problem scope I carried out the following steps:

1. Created a new C# Web API project.
2. Added the System.Data.SQLite.Core NuGet package.
3. Added the code shown below.
4. Added a publish profile to publish to the local file system and published it.
5. Ran the following IISExpress command iisexpress /path:c:\\path-to-application /port:8081
6. Navigated to http://localhost:8081/api/values in the browser which correctly responds with the rows from the relevant SQLite table

If we then try to publish again we receive the error described above, which echoes the problem we see in production under IIS .

In order to successfully deploy to the production site we have to stop the app pool , publish and then restart the app pool .

This is far from ideal. Any thoughts on how we can resolve this issue?

Here's the code ...

public IEnumerable<string> Get()
{
    var dbPath = HttpContext.Current.Server.MapPath("~/MyDB.sqlite");
    using (var conn = new SQLiteConnection(string.Format("Data Source={0};Version=3;", dbPath)))
    {
        var rows = new List<string>();
        conn.Open();
        var sql = "select * from myTable";
        using (var command = new SQLiteCommand(sql, conn))
        {
            using (var reader = command.ExecuteReader())
            {
                while (reader.Read())
                {
                    rows.Add(reader["mycolumn"].ToString());
                }
            }
        }
        return rows;
    }
}

Answer 1

You must stop the web site during deployment. You should had done that anyway , irrelevant of the DLL locking, because requests handled during the deployment will yield unpredictable results from mixing old and new code.