CopySQLiteInteropFiles not working with dotnet build?
(1) By Jonathan Brecher (jbrecher) on 2021-06-28 17:16:45 [link] [source]
After upgrading to Visual Studio 16.10.2, CopySQLiteInteropFiles is working again for builds from within Visual Studio. Thanks to everyone who worked on that fix!
Unfortunately, it is NOT working for builds from the command line using
dotnet build. A verbose log shows this:
12:58:36.624 2:9>Target "CopySQLiteInteropFiles: (TargetId:179)" in file "C:\Users\jbrecher\.nuget\packages\stub.system.data.sqlite.core.netframework\1.0.114\buildTransitive\net46\Stub.System.Data.SQLite.Core.NetFramework.targets" from project "C:\src\path\to\project.csproj" (target "Build" depends on it): Skipping target "CopySQLiteInteropFiles" because it has no outputs. Though the target has declared its outputs, the output specification only references empty properties and/or empty item lists.
This is the same thing that was reported for 16.10.0 at https://developercommunity.visualstudio.com/t/after-installing-vs-v16100-build-target-no-longer/1432786. Do I need a separate upgrade to get
dotnet build to work?
(2) By Warren Young (wyoung) on 2021-06-28 18:20:27 in reply to 1 [source]
Depending on your project settings, you might need a manual call to dotnet restore to force an update.
If that’s not it, post the package reference element of your project file.
(3) By Jonathan Brecher (jbrecher) on 2021-06-28 18:34:44 in reply to 2 [link] [source]
The project should be pretty vanilla (other dependencies trimmed):
<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop"> <PropertyGroup> <OutputType>WinExe</OutputType> <ApplicationIcon>..\..\shared\AppIcon.ico</ApplicationIcon> <UseWPF>true</UseWPF> <ContentSQLiteInteropFiles>true</ContentSQLiteInteropFiles> <GenerateResourceUsePreserializedResources>true</GenerateResourceUsePreserializedResources> </PropertyGroup> <ItemGroup> <PackageReference Include="System.Data.SQLite.Core" Version="126.96.36.199" /> </ItemGroup> </Project>
I saw there was a 188.8.131.52 version released a week or two ago, and I upgraded to that as a test but it didn't change anything.
I did notice that
dotnet build --version reports
184.108.40.206001. If the fix was only released in 16.10.2, that would explain why I don't see the fix. Maybe Microsoft forgot to include the updated version of
dotnet build in the same update that had the fix in Visual Studio?
Does anyone have a 16.10.2 version of
dotnet build on their machine, or can they confirm that the fix IS present in 16.0.1?