A bug in SourceGear.sqlite3.3.50.4.5, to place e_sqlite3.dll in a wrong directory

[viruscamp]

It's a bug in SourceGear.sqlite3.3.50.4.5, one dependency of this lib.

With old style msbuild csproj, and place *.sln and *.csproj in the same directory.
Like this, It will place e_sqlite3.dll in a wrong directory.

WindowsFormsApp4\
	WindowsFormsApp4.sln
	packages\SourceGear.sqlite3.3.50.4.5\...
	WindowsFormsApp4.csproj
	bin\x64\Debug\
		WindowsFormsApp4.exe
		packages\SourceGear.sqlite3.3.50.4.5\runtimes\win-x64\native\e_sqlite3.dll

When we place *.sln and *.csproj in different directories, It's right.

WindowsFormsApp4\
	WindowsFormsApp4.sln
	packages\SourceGear.sqlite3.3.50.4.5\...
	WindowsFormsApp4\
		WindowsFormsApp4.csproj
		bin\x64\Debug\
			WindowsFormsApp4.exe
			e_sqlite3.dll

The bug is from SourceGear.sqlite3.targets file

  <ItemGroup Condition=" '$(RuntimeIdentifier)' == '' AND '$(OS)' == 'Windows_NT' AND '$(Platform)' == 'x64' ">
    <Content Include="$(MSBuildThisFileDirectory)..\..\runtimes\win-x64\native\e_sqlite3.dll">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <Pack>false</Pack>
    </Content>
  </ItemGroup>

should be, to use runtimes dir

  <ItemGroup Condition=" '$(RuntimeIdentifier)' == '' AND '$(OS)' == 'Windows_NT' AND '$(Platform)' == 'x64' ">
    <Content Include="$(MSBuildThisFileDirectory)..\..\runtimes\win-x64\native\e_sqlite3.dll">
      <Link>runtimes\win-x64\native\e_sqlite3.dll</Link>
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <Pack>false</Pack>
    </Content>
  </ItemGroup>

or , to keep the old version structure

  <ItemGroup Condition=" '$(RuntimeIdentifier)' == '' AND '$(OS)' == 'Windows_NT' AND '$(Platform)' == 'x64' ">
    <Content Include="$(MSBuildThisFileDirectory)..\..\runtimes\win-x64\native\e_sqlite3.dll">
      <TargetPath>e_sqlite3.dll</Link>
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <Pack>false</Pack>
    </Content>
  </ItemGroup>

[ericsink]

Thanks for the investigation here. I've had a few recent reports of this kind of problem, but had difficulty reproducing it. I'll take another look, using the information you've provided.

[viruscamp]

Thanks for the investigation here. I've had a few recent reports of this kind of problem, but had difficulty reproducing it. I'll take another look, using the information you've provided.

To be clear, the new SDK style csproj like <Project Sdk="Microsoft.NET.Sdk.WindowsDesktop"> won't be affected by the bug.

Only the old MSBuild style csproj like <Project ToolsVersion="4.0"> is affected.

You have to create project in VS2019, because as I know VS2022 and VS2026 create SDK style by default.