System.Data.SQLite

Login
This project makes use of Eagle, provided by Mistachkin Systems.
Eagle: Secure Software Automation
Ticket Hash: dbbacbd84177348a7138fd1872b5a77e195b8830
Title: Make builds with both native interop files as linked resources
Status: Open Type: Feature_Request
Severity: Cosmetic Priority: Medium
Subsystem: Integration_Via_PInvoke Resolution: Open
Last Modified: 2013-04-19 13:58:12
Version Found In:
User Comments:
anonymous added on 2013-02-28 14:17:40:

As it is right now you have to manually add the x86 and x64 versions of SQLite.Interop.dll to a project (or ensure they are copied to the output dir in some other way) if you want it to both work on 32-bit and 64-bit architectures while taking advantage of the 64-bit architecture when available. Also this makes it impossible to install System.Data.SQLite into the GAC.

.NET actually has a facility for exactly a case like this: linked resources. It simply adds metadata to the assembly manifest that tells that an external file belongs to the assembly. It will make msbuild copy the interop files correctly to the output dir when System.Data.SQLite is referenced, and will make it work properly when added to the GAC.


mistachkin added on 2013-02-28 22:14:04:
The entire build process would have to be modified to force the native interop
library projects to be built first, for multiple platforms.  This is not easy
to accomplish using the Visual Studio IDE, nor MSBuild.  It would be an external
piece of automation.

anonymous added on 2013-04-19 13:58:12:
Actually it is impossible to add relative paths to linked resources - csc, al and link only uses the filename part. Adding them to the assembly with relative path using Mono.Cecil results in the relative path being used by msbuild when looking for the resource, but ignored when it copies the files to the output dir - i.e. both 32bit and 64bit versions ends directly in the output directory overwriting whichever was the first one listed in the assembly.

So for this to work we would have to rename the interop dlls themselve according to the architecture.

- Kasper Brandt (poizan@poizan.dk)