Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add-Migration doesn't work in a UWP project with EF Core 1.0.1 #6551

Closed
qmatteoq opened this issue Sep 16, 2016 · 7 comments
Closed

Add-Migration doesn't work in a UWP project with EF Core 1.0.1 #6551

qmatteoq opened this issue Sep 16, 2016 · 7 comments
Assignees

Comments

@qmatteoq
Copy link

Steps to reproduce

  1. Install the packages required to use EF Core in a UWP application by following the guideline explained here: http://ef.readthedocs.io/en/latest/platforms/uwp/
  2. Notice that, by default, NuGet install the last version of the package, which is 1.0.1
  3. Follow the tutorial to create the model and the DbContext class
  4. Run the NuGet command to perform the migration
Add-Migration MyFirstMigration

The issue

The migration fails with the following exception

Add-Migration : Exception calling "CreateInstanceAndUnwrap" with "8" argument(s): "Could not load file or assembly 'Microsoft.EntityFrameworkCore, Version=1.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' or one of its 
dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)"
At line:1 char:1
+ Add-Migration MyFirstMigration
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Add-Migration], MethodInvocationException
    + FullyQualifiedErrorId : FileLoadException,Add-Migration

The only way to get the migration working is to revert back all the NuGet packages to version 1.0.0

Further technical details

EF Core version: 1.0.1
Operating system: Windows 10 14393.105
Visual Studio version: Visual Studio 2015 Update 3

Other details about my project setup: Simple project created for test purposes, with just one entity and some basic operations (Inserting and retrieving data).

@allanrsmith
Copy link

Do you have multiple projects? i.e. One UWP App and one Library that is the EF stuff? If so, I think the tooling (which is stale) needs you to add a reference to EntityFramework on the UWP project too.

@divega
Copy link
Contributor

divega commented Sep 16, 2016

@qmatteoq we suspect this might be due to the fact that we execute the code in .NET Framework and resolving to a newer version of the EF Core assemblies would require binding redirects, which are not added in this case to the UWP project. If this is correct it should be possible to add the binding redirect manually, in a similar way to how it is explained in #5945 (comment) (but that was for a different assembly).

@Librazy
Copy link

Librazy commented Sep 18, 2016

Inspired by @divega I found a workaround for assemblies resolving. Just add binding redirect

      <dependentAssembly>
        <assemblyIdentity name="Microsoft.EntityFrameworkCore" publicKeyToken="adb9793829ddae60" culture="neutral" />
        <bindingRedirect oldVersion="1.0.0.0" newVersion="1.0.1.0"/>
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.EntityFrameworkCore.Relational" publicKeyToken="adb9793829ddae60" culture="neutral" />
        <bindingRedirect oldVersion="1.0.0.0" newVersion="1.0.1.0"/>
      </dependentAssembly>

The full version of App.config I'm using now (on exactly the same environment of @qmatteoq , works fine)

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.IO.FileSystem.Primitives" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="4.0.0.0" newVersion="4.0.1.0"/>
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Threading.Overlapped" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="4.0.0.0" newVersion="4.0.1.0"/>
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.ComponentModel.Annotations" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="4.1.0.0" newVersion="4.0.0.0"/>
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.EntityFrameworkCore" publicKeyToken="adb9793829ddae60" culture="neutral" />
        <bindingRedirect oldVersion="1.0.0.0" newVersion="1.0.1.0"/>
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.EntityFrameworkCore.Relational" publicKeyToken="adb9793829ddae60" culture="neutral" />
        <bindingRedirect oldVersion="1.0.0.0" newVersion="1.0.1.0"/>
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

@qmatteoq
Copy link
Author

Thanks @Librazy your workaround worked fine. By manually setting the bindings, I was able to complete the Add-Migration command with success even by using version 1.0.1.

@allanrsmith no, everything is in the same project, the model and the context are defined directly in the UWP app

@qmatteoq
Copy link
Author

Is there any plan to find a long term fix to this problem which doesn't require to manually setting the app.config? I'm asking because I'm writing a book about UWP development and I'm planning to write about EF Core in the chapter dedicated to storage. However, the app.config solution doesn't look great in terms of documenting it, because every time you're going to release a new minor update of EF Core, the app.config sample I could include in the book becomes not valid anymore.

@ErikEJ
Copy link
Contributor

ErikEJ commented Sep 18, 2016

I think this is already in progress of being fixed: #6555

@bricelam
Copy link
Contributor

This can probably be considered a dupe of #5471 now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants