|Title:||Interop dll files (x86/x64 folders) are not copied after build|
|Last Modified:||2018-11-07 02:17:00|
|Version Found In:||1.0.108 & 22.214.171.124|
anonymous added on 2018-10-05 12:13:24:
When building our solution that uses System.Data.SQLite version 1.0.108 on Visual Studio version > 15.8.5 (we have experienced the issue on both 15.8.5 and .6), the Interop.dll files (on both x86 and x64 folders) are not copied systematically. Sometimes after a few build/rebuild they appear, but after a clean they never appear. Until now (probably with the update of Visual Studio) it was working correctly, and we haven't changed anything in our projects configuration for a while. A colleague had a earlier version of Visual Studio (15.8.0) and it was working correctly, but as soon as he updated to 15.8.6 it stopped working. The issue is reproducible on a minimal project (tested on a new WinForms project) with the System.Data.SQLite NuGet package version 126.96.36.199 installed. We can't see any error in the output during the build (but obviously the app fails at runtime, missing the dll). We've also seen that the issue doesn't appear on our build server. We're using Azure DevOps that uses MSBuild.
mistachkin added on 2018-10-06 16:51:44:
Do you have build logs? That will help us to diagnose the issue. When setting up logging for MSBuild, the "/verbosity:diagnostic" option is recommended.
mistachkin added on 2018-10-08 21:13:32:
It seems like the "..\packages\System.Data.SQLite.Core.188.8.131.52\build\net46\System.Data.SQLite.Core.targets" file is not being imported even thought it exists. Does the project file itself contain the <Import> element for this file (i.e. one that was added by NuGet)?
anonymous added on 2018-10-09 06:25:07:
Yes it does contain the <import> added by Nuget... Have a look at this minimal project : https://cloudix.rollomatic.ch/url/658iefgbjb49wyv9 The application build, but you'll notice that the x86/x64 folder are not always copied in the output bin. Sometimes it does (after a clean and a second build) but not always. One more time, it did work well with VS2017 15.8.0 but the behaviour changed with 15.8.6.
mistachkin added on 2018-10-09 11:50:38:
Given your description, this may be a bug (regression) in Visual Studio. I'm not sure what I can do to fix it.
mistachkin added on 2018-10-09 11:56:07:
Looking at the project file, my first guess is that the relative path to the "System.Data.SQLite.Core.targets" file is a problem. Relative paths typically are based on the current directory, which may not be well-defined when building within the IDE. It's certainly possible that my guess is wrong. The Visual Studio team may know more about why this setup suddenly stopped working. Perhaps there is some third-party plugin or tool that is changing the current directory during the build process?
mistachkin added on 2018-10-10 16:03:40:
One thing to try is to make sure that "parallel build" is disabled. It may cause various issues, according to information that I have read.
anonymous added on 2018-10-11 08:57:23:
I also report this issu to the Visual Studio's Developer Community, but didn't recieved a response yet. The relative path to the "System.Data.SQLite.Core.targets" is set automatically in the csproj when adding your nuget to the project. I didn't changed anything. I also tried to build without "parallel build" it didn't change anything. Did you reproduce the bug with the minimal project I sent you? Here is the "step by step" bug I sent to VS2017 : - Create a new solution (Windows Forms .Net 4.6.2) - Add System.Data.SQLite version 1.0.108 or higher (it didn't work with 1.0.109 neither) - Build project : the x86/x64 folders are in bin/debug (it works in this case) - Close Visual Studio - Remove packages/bin/obj folders - Open solution / Restore nuget / Build : The x86/x64 folders are missing. The behavior after a clean in Visual Studio is not always the same, sometimes after cleaning the solution and building again make them appear, sometimes not.
mistachkin added on 2018-10-12 11:07:49:
Given the behavior you've described, I suspect this behavior can only be fixed by the Visual Studio team. There may be a workaround; however, I'm not aware of one.