How to use nuget.targets file to save two DLLs with same name but different target architecture into output respective folders in output directory

Question

I have a problem with SQLite.Interop.dll library. I am required to use x64 and x86 distribution of it. I also need both of them to be copied into output directory in

x64/SQLite.Interop.dll

and

x86/SQLite.Interop.dll

folders respectively.

I created a Nuget package with following nuspec file:

<?xml version="1.0"?>
<package >
  <metadata minClientVersion="2.5">
    <id>SQLite.Interop</id>
    <version>1.1.18</version>
    <authors>SQLite</authors>
    <owners>That's me</owners>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>That's for me.</description>
    <copyright>Copyright 2018</copyright>
    <tags>SQLite Interop ofcMe</tags>
    <dependencies>
    </dependencies>
  </metadata>
    <files>
        <file src="content\x86\SQLite.Interop.dll" target="content\x86\SQLite.Interop.dll" />
        <file src="content\x64\SQLite.Interop.dll" target="content\x64\SQLite.Interop.dll" />
        <file src="bin\Debug\x64\SQLite.Interop.dll" target="Build\x64\" />
        <file src="bin\Debug\x86\SQLite.Interop.dll" target="Build\x86\" />
        <file src="SQLite.Interop.targets" target="Build\" />
    </files>
</package>

And following SQLite.Interop.targets file:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ItemGroup>
    <None Include="@(MSBuildThisFileDirectory)x64\SQLite.Interop.dll">
      <Link>SQLite.Interop.dll</Link>
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </None>
    <None Include="@(MSBuildThisFileDirectory)x86\SQLite.Interop.dll">
      <Link>SQLite.Interop.dll</Link>
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </None>
  </ItemGroup>
</Project>

How to archive this after application builds?

Answer 1

I added an SQLite.Core reference to projects that needed SQLite.Interop in their output directory as it had nessessary scripts in it's nuget package.

I know this is kinda a workaround but it solved my problem at the cost of a little, low size library reference.