2

I've been trying to work this out for a little while now and I can't see how it's possible, which seems odd given that .NET Core is properly released and EF6 is still recommended for some mainline cases. However, I'm new to .NET Core, so hopefully I'm just missing something obvious.

I have a ASP.NET Core Web Application and have been trying to add EF models and migrations in a separate project. I've tried two main paths and both have hit different road blocks.

Attempt 1: Create the EF library as an old fashioned class library

This works OK within Visual Studio (although you have to mess around with the start-up project), but when I try to use "dotnet restore" to build things from the command line (so I can get my CI set up) I get:

Errors in C:\MyProject\src\My.Website\project.json
Unable to resolve 'My.DataModel' for '.NETFramework,Version=v4.5.2'.

Using the "dotnet" command appears to be the new way of running command line builds, but perhaps it's not the right way for this case?

Attempt 2: Create EF library as a .NET Core class library

This way fixes the error when running "dotnet restore" but has the rather more fatal flaw of breaking the package manager console commands for creating migrations (they appear to require a .csproj file to work). This answer looked like it might be a solution, but I couldn't get it to work for me.

I think that my attempt 1 is more likely to be the right way to go. In which case this question may boil down to "how do I use 'dotnet restore' with non-.NETCore libraries?"

I've just found this thread, I've tried a few things from there and they haven't worked yet, but I'll keep looking at it.

Community
  • 1
  • 1
Dan
  • 7,446
  • 6
  • 32
  • 46

1 Answers1

1

As far as I can tell the answer is "No" if you want what I would consider a sensible CI set up. If you can run a full install of VS2015 on the CI server you may be able to get this to work somehow.

I got further with my attempt 1 but ended up at what looks like a terminal (at the moment) road block. Currently Visual Studio 2015 will create lock.json files that correctly include my EF project. However, running "dotnet.exe restore" will then remove the lines referencing my EF project and break the build.

I hope that eventually dotnet.exe will catch up with Visual Studio and correctly handle project dependencies but for now this seems like a terminal issue. Even if I commit the lock.json files to source control the CI server needs to run dotnet restore to pull down dependencies and so will break the lock.json files.

I had to jump through quite a few other hoops to get this far, so I'll document them below in case it helps anyone else.

Nuget

You need to install nuget onto your build server (or have your build download it). This is probably fairly common, but our build server didn't have nuget already on it. I have tried nuget 2.8.6 which appears to only download the .csproj dependencies, and nuget 3.5.0-rc1 which appears to behave very similarly to dotnet.exe.

Dotnet

Again you need to install this on the build server (not unreasonable). However it will produce an error when trying to handle the project dependency so you may need to ensure that your build doesn't fail at that point (e.g. by doing this)

Msbuild

At this point my local Msbuild complained about the EF project with:

Your project.json doesn't list 'win' as a targeted runtime. You should add '"win": { }' inside your "runtimes" section in your project.json, and then re-run NuGet restore.

That project didn't have a project.json file at all at that point so I added one with the following contents:

        {
        "frameworks": {
            "net452": {
            }
        },

        "runtimes": {
            "win": {}
        }
    }

As hinted at on this thread. Although I've just noticed that the presence of this file stops nuget 3.5.0-RC1 from downloading the Entity Framework dependency for my EF project at all (Nuget 2.8.6 ignores this file and downloads EF fine)

The end

At this point my local msbuild will build the project as long as I've opened it in VS2015 so that VS2015 has had a chance to build the correct lock.json files.

On my CI server if I comment out the "dotnet restore" step and commit my lock files to source control my EF project reference isn't a problem any more (I still have an issue with the reference to Entity Framework itself, but that's probably a separate issue). However, leaving out the dotnet restore step is not a viable solution - things are only working because that step was there before and has already downloaded the relevant dependencies.

Note that if you're going to try to reproduce this, VS2015 will notice and re-write the lock.json files back to a working version immediately if you run "dotnet restore" so you need to close VS2015 or have a separate checkout to see the issue.

Community
  • 1
  • 1
Dan
  • 7,446
  • 6
  • 32
  • 46