System.Data.SQLite

The current installer version installs System.Data.Sqlite.dll and System.Data.Sqlite.Linq.dll in such a way that they are picked up by .NET 4.0 projects as well as .NET 4.5 projects. This causes build warnings or errors.

To reproduce: start with a machine with sqlite-netFx451-setup-bundle-x86-2013-1.0.94.0.exe installed (including the VS2013 design components). Create a new .NET 4.0 class library and add the NuGet package System.Data.Sqlite (current version is 1.0.94.1). Place this code in the class library:

    public class Class1
    {
        public SQLiteConnection Test()
        {
            return null;
        }
    }

Add a .NET 4.0 console application referencing this library. Add the NuGet package System.Data.Sqlite, and use this code:

    class Program
    {
        static void Main(string[] args)
        {
            new Class1().Test().Close();
        }
    }

When building, you'll get this warning:

C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3274: The primary reference "System.Data.SQLite.Linq, Version=1.0.94.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139, processorArchitecture=MSIL" could not be resolved because it was built against the ".NETFramework,Version=v4.5.1" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v4.0".

In this simple solution, it is only a warning. In our real-world (much more complex) solution, this actually prevents us from building. Our only current workaround is to uninstall the bundle package with the VS2013 design components, which makes me sad.

Note that there was an earlier VS2013 install package that did *not* cause this problem. I'm not sure which version that was.

I believe this is similar to the Newtonsoft.Json problem described here on Stack Overflow which was caused by the Azure SDK installer.

To summarize, the wrong AssemblyFoldersEx key is being written to by the
design-time installer for System.Data.SQLite?

Setting to blocker.

It would be very helpful to have the setup logs.

The log files should be located in the %TEMP% directory on the machine.  They
will have names similar to "Setup Log 2014-11-18 #001.txt" and
"Installer.exe.trace.tmp29.log".

I've attached the installer logs. I actually suspect the problem is with the GAC'ed assemblies and not the AssemblyFoldersEx key.

I've reviewed the log files.  Everything appears to be working correctly with
regards to the AssemblyFoldersEx keys.

I'm not sure how this issue can be fixed if the problem is with the GAC.  Is
there some way to support side-by-side versions of the same assembly when one
of them is targeting .NET Framework 4.0 and another is targeting the .NET
Framework 4.5.1?

There might be a way to prevent the project from referencing assemblies present
in the GAC (e.g. if you set the HintPath in the project file itself).