Error building Tools

Topics: EF Designer
Nov 6, 2013 at 5:34 PM
I get this error when Building the tools:

Error 128 Assembly 'Microsoft.VisualStudio.Data.Tools.Design.XmlCore, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' uses 'Microsoft.VisualStudio.XmlEditor, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' which has a higher version than referenced assembly 'Microsoft.VisualStudio.XmlEditor, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' c:\Data\SQLCE\EF6\nogonomore\bin\Debug\Microsoft.VisualStudio.Data.Tools.Design.XmlCore.dll EntityDesign

Seems like the EntityDesign project references the wrong DLL version
Nov 6, 2013 at 6:22 PM
@Erik - are you sure you are building this from the Visual Studio command prompt? If you look at the XmlCore.csproj file you will see that the version is determined using the $(VisualStudioVersion) variable i.e.:

<Reference Include="Microsoft.VisualStudio.XmlEditor, Version=$(VisualStudioVersion).0.0, Culture=neutral, PublicKeyT
oken=b03f5f7f11d50a3a, processorArchitecture=MSIL" />

The VisualStudioVersion variable should be set (automatically) to '11.0' if you are using the Developer Command Prompt for VS2012 but it appears to be set to Since the Microsoft.VisualStudio.XmlEditor is a VS thing (as opposed to .Net Framework) I would think that the version is never correct. If your settings are correct but the issue persists can you open a bug for this and attach a build log created with the diagnostic verbosity?
Nov 6, 2013 at 7:08 PM
@Moozyk - thanks for your quick reply. The issue is not with the XmlCore.csproj file, but the EntityDesign.csproj file (sorry if that was unclear)

Actually, version 3.5 is correct for the VS 2008 version, located here on my machine: C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies

As version hint like in the XmlCore.csproj file added to the EntityDesign.csproj file would fix the issue, I think.
Nov 6, 2013 at 7:54 PM
@Erik - I did not know that VS2008 used 3.5 - that's interesting. I think I still don't understand how you end up with VisualStudioVersion being set to 3.5 in the VS2012 (or VS2013) environment - can you elaborate more on this? Note that we don't support building (or running) the new EFTooling on versions of VS older than VS2012. Setting the version hint may fix this particular problem but won't really work since this variable is being used in many other places (e.g. to include version specific xaml files <Compile Include="UI\Views\Dialogs\EnumTypeDialog_$(VisualStudioVersion).xaml.cs"> and there is no EnumTypeDialog_3.5.xaml.cs).
Nov 7, 2013 at 6:54 AM
Edited Nov 7, 2013 at 6:56 AM
I do not end up with a VisualStudioVersion set to 3.5.

Look in the EntityDesign.csproj file, it does not have a version hint for Microsoft.VisualStudio.XmlEditor like in the XmlCore.csproj file. So this project does not respect any VS version variables for this particular reference.

Look at:
<Reference Include="Microsoft.VisualStudio.XmlEditor" />
So in other words, use of the the versioned reference is not consistent. making that consistent should fix the issue
Nov 7, 2013 at 1:22 PM
Got it. I am still not sure why MSBuild wants to use version here but it does not matter too much. We typically don't have VS2008 installed and therefore we have not run into this issue. I will try to get it fixed today. Thanks for your patience (and reporting this).
Nov 7, 2013 at 1:25 PM
Edited Nov 8, 2013 at 12:16 PM
Thanks, no rush, it was easy to fix by hand...

FYI, MSBuild resolves references as described here: (from MS.Common.targets)
    The SearchPaths property is set to find assemblies in the following order:

        (1) Files from current project - indicated by {CandidateAssemblyFiles}
        (2) $(ReferencePath) - the reference path property, which comes from the .USER file.
        (3) The hintpath from the referenced item itself, indicated by {HintPathFromItem}.
        (4) The directory of MSBuild's "target" runtime from GetFrameworkPath.
            The "target" runtime folder is the folder of the runtime that MSBuild is a part of.
        (5) Registered assembly folders, indicated by {Registry:*,*,*}
        (6) Legacy registered assembly folders, indicated by {AssemblyFolders}
        (7) Resolve to the GAC.
        (8) Treat the reference's Include as if it were a real file name.
        (9) Look in the application's output folder (like bin\debug)
Nov 7, 2013 at 4:17 PM
Fixed in 1e1d88944cb5