System.Data.SQLite

Login
This project makes use of Eagle, provided by Mistachkin Systems.
Eagle: Secure Software Automation
Ticket Hash: d1f023535691b5fee432825eacce77d569fed087
Title: VS design-time installer writes to the wrong AssemblyFoldersEx key
Status: Closed Type: Incident
Severity: Important Priority: Blocker
Subsystem: VsDesignerInstaller Resolution: Works_As_Designed
Last Modified: 2014-11-25 06:46:01
Version Found In: sqlite-netFx451-setup-bundle-x86-2013-1.0.94.0.exe
User Comments:
anonymous added on 2014-11-19 17:05:44: (text/html)
<p>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.</p>

<p>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:</p>

<pre>
    public class Class1
    {
        public SQLiteConnection Test()
        {
            return null;
        }
    }
</pre>

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

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

<p>When building, you'll get this warning:</p>

<pre>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".
</pre>

<p>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.</p>

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

<p>I believe this is similar to the Newtonsoft.Json problem <a href="http://stackoverflow.com/questions/24922637/visual-studio-is-throwing-a-wrong-compile-time-exception">described here on Stack Overflow</a> which was caused by <a href="https://connect.microsoft.com/VisualStudio/feedback/details/850425/windows-azure-vs-tools-breaking-msbuild-for-web-projects">the Azure SDK installer</a>.</p>

mistachkin added on 2014-11-19 20:31:39: (text/x-fossil-plain)
To summarize, the wrong AssemblyFoldersEx key is being written to by the
design-time installer for System.Data.SQLite?

mistachkin added on 2014-11-19 20:31:52: (text/x-fossil-plain)
Setting to blocker.

mistachkin added on 2014-11-19 20:35:36: (text/x-fossil-plain)
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".

anonymous added on 2014-11-20 15:24:21: (text/x-fossil-plain)
I've attached the installer logs. I actually suspect the problem is with the GAC'ed assemblies and not the AssemblyFoldersEx key.

mistachkin added on 2014-11-20 20:33:59: (text/x-fossil-plain)
I've reviewed the log files.  Everything appears to be working correctly with
regards to the AssemblyFoldersEx keys.

mistachkin added on 2014-11-20 20:36:38: (text/x-fossil-plain)
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?

mistachkin added on 2014-11-20 20:37:52: (text/x-fossil-plain)
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).