View Ticket
Not logged in
Ticket UUID: 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-
User Comments:
anonymous added on 2014-11-19 17:05:44:

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- 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 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=, 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.

mistachkin added on 2014-11-19 20:31:39:
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:
Setting to blocker.

mistachkin added on 2014-11-19 20:35:36:
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

anonymous added on 2014-11-20 15:24:21:
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:
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:
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:
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).