VS2015 file in use

Hello,

When I start VS2015 and my project opens my SQL.fs file, where the SqlDataProvider is 'typed', it seems SqlDataProvider wins a race to the FSharp.Data.SqlProvider.dll and locks it, making 'rebuild' of a project not possible:

Severity    Code    Description Project File    Line
Error       Unable to copy file "obj\Debug\FSharp.Data.SqlProvider.dll" to "..\..\bin\FSharp.Data.SqlProvider.dll". The process cannot access the file '..\..\bin\FSharp.Data.SqlProvider.dll' because it is being used by another process. SqlProvider C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets 3812

To fix, I need to close the SQL.fs file, then close visual studio, then restart visual studio.

Edit: I am not sure if this a SqlProvider issue, I have heard vs2015 is bad at locking files an that Update1 will help to fix some of these issues.

I went through the SqlProvider and:

• Updated ProvidedTypes-head, fs and fsi to be compat with 4.0.
• Replaced all instances of Assembly.LoadFrom(x) with Assembly.Load(IO.File.ReadAllBytes x)

No dice so far.
Edit:

• Upgrading to VS2015 Update1 does not resolve the issue.

[mFingers]

Yes, very annoying. Seems like this is a known issue working with type providers. This article calls it out, and this one suggests opening a second instance of Visual Studio to test the provider out. Although you will need to restart that editor if you want to make a change to the code and recompile it (I suppose that method is less jarring to the programmer?). I don't know if there is an elegant way to handle this. I'd be interested to hear how @colinbull and @pezipink handle this workflow. :)

[janno-p]

I think this issue is more about tooling than SqlProvider. One thing that was possible to improve, is already done: earlier when solution file included test project, only way to compile more than once, was to somehow disable test project (by unloading it for example), because after first build, test project locked sqlprovider dll. At the moment, test project is not included in the main solution anymore, which makes working with sqlprovider more convenient.

My personal preference when working on type providers, is to run type provider itself in Visual Studio instance and test it out by scripting in some lighter editor which is easier to reload (Visual Studio Code + Ionide, Tsunami, etc.)

[bizmonger]

I hit the same issue after I upgraded to Visual Studio 2019 version 16.5.0 Preview 1.0.
I'm stuck with a bad build now for the solution that I have.