dotnet cli does not embed csdl,msl, or ssdl files

[AleksandrAlbert]

Steps to reproduce

• Add an ADO.NET entity data model to aspnet core project
• Generate a database first model (.edmx)
• Build project using visual studio 2017
• Inspect generated dll (using ILSpy or similar)
• Build project using dotnet build from cli
• Inspect generated dll

Expected behavior

Both Visual Studio and cli should embed csdl, msl, and ssdl files into dll as resources.

Actual behavior

Only Visual Studio embeds these files. When built through cli, files are not embedded and a Metadata exception is thrown when accessing the model.

Environment data

dotnet --info output:

.NET Command Line Tools (2.1.2)

Product Information:
Version: 2.1.2
Commit SHA-1 hash: 5695315

Runtime Environment:
OS Name: Windows
OS Version: 10.0.15063
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\2.1.2\

Microsoft .NET Core Shared Framework Host

Version : 2.0.3
Build : a9190d4a75f4a982ae4b4fa8d1a24526566c69df

---

This problem only began when I moved my project from vs2015 to vs2017. I was able to use the cli just fine before.

[livarcocc]

This is not supported in the CLI. These types of files are supported in MSBuild props/targets that don't ship in the CLI and only ship in full framework VS. Have you tried using msbuild instead of dotnet build for this?

[AleksandrAlbert]

@livarcocc Yes it does seem to work with MSBuild. What I find confusing is how I was able to run my project using 'dotnet run' on vs2015 and not get this error. Now I'm scared to publish (its an Azure Web App) as I am afraid that Azure may use dotnet build in the background and break my currently working site (haven't published since I switched), is this likely to happen? Is there some way to tell 'dotnet run' not to build the project containing my edmx file?

[livarcocc]

I am not sure how it worked in vs2015. Do you have a project.json file that vs2015 was using? Anyways, isn't there an option for you to publish your built app, instead of have it be built in the cloud? I am sorry, don't know much about that anymore.

[AleksandrAlbert]

@livarcocc I was able to find the old project.json in my git history, here it is:

{
  "userSecretsId": "xxx",

  "dependencies": {
    "Microsoft.AspNetCore.Authentication.Cookies": "1.0.0",
    "Microsoft.AspNetCore.Diagnostics": "1.0.0",
    "Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore": "1.0.0",
    "Microsoft.AspNetCore.Identity.EntityFrameworkCore": "1.0.0",
    "Microsoft.AspNetCore.Mvc": "1.0.0",
    "Microsoft.AspNetCore.Razor.Tools": {
      "version": "1.0.0-preview2-final",
      "type": "build"
    },
    "Microsoft.AspNetCore.Server.IISIntegration": "1.0.0",
    "Microsoft.AspNetCore.Server.Kestrel": "1.0.0",
    "Microsoft.AspNetCore.StaticFiles": "1.0.0",
    "Microsoft.EntityFrameworkCore.SqlServer": "1.0.0",
    "Microsoft.EntityFrameworkCore.SqlServer.Design": {
      "version": "1.0.0",
      "type": "build"
    },
    "Microsoft.EntityFrameworkCore.Tools": {
      "version": "1.0.0-preview2-final",
      "type": "build"
    },
    "Microsoft.Extensions.Configuration.EnvironmentVariables": "1.0.0",
    "Microsoft.Extensions.Configuration.Json": "1.0.0",
    "Microsoft.Extensions.Configuration.UserSecrets": "1.0.0",
    "Microsoft.Extensions.Logging": "1.0.0",
    "Microsoft.Extensions.Logging.Console": "1.0.0",
    "Microsoft.Extensions.Logging.Debug": "1.0.0",
    "Microsoft.Extensions.Options.ConfigurationExtensions": "1.0.0",
    "Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.0.0",
    "Microsoft.VisualStudio.Web.CodeGeneration.Tools": {
      "version": "1.0.0-preview2-final",
      "type": "build"
    },
    "Microsoft.VisualStudio.Web.CodeGenerators.Mvc": {
      "version": "1.0.0-preview2-final",
      "type": "build"
    }
  },

  "tools": {
    "BundlerMinifier.Core": "2.0.238",
    "Microsoft.AspNetCore.Razor.Tools": "1.0.0-preview2-final",
    "Microsoft.AspNetCore.Server.IISIntegration.Tools": "1.0.0-preview2-final",
    "Microsoft.EntityFrameworkCore.Tools": "1.0.0-preview2-final",
    "Microsoft.Extensions.SecretManager.Tools": "1.0.0-preview2-final",
    "Microsoft.VisualStudio.Web.CodeGeneration.Tools": {
      "version": "1.0.0-preview2-final",
      "imports": [
        "portable-net45+win8"
      ]
    }
  },

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

  "buildOptions": {
    "emitEntryPoint": true,
    "preserveCompilationContext": true
  },

  "publishOptions": {
    "include": [
      "wwwroot",
      "Views",
      "Areas/**/Views",
      "appsettings.json",
      "web.config"
    ]
  },

  "scripts": {
    "prepublish": [ "bower install", "dotnet bundle" ],
    "postpublish": [ "dotnet publish-iis --publish-folder %publish:OutputPath% --framework %publish:FullTargetFramework%" ]
  }
}

[livarcocc]

I would suggest that you publish your binaries instead of relying in clould build for this case.

cc @ajcvickers @divega for comments on these files not being supported in the CLI.

[divega]

@livarcocc I can describe at a high level how this works in a project with MSBuild, but I am sure your understanding of why these don't work in CLI (or if there are possible workarounds) can be better than mine:

1. If you use database-first with EF6 or a previous versions of EF, your project file will contain a reference to your .edmx file (which contains the EF model and mappings), e.g.:

    <EntityDeploy Include="MyModel.edmx">
      <Generator>EntityModelCodeGenerator</Generator>
      <LastGenOutput>Model1.Designer.cs</LastGenOutput>
    </EntityDeploy>

2. MSBuild ships with a couple of shim Microsoft.Data.Entity.targets files at “C:\Program Files (x86)\MSBuild” and “C:\Program Files (x86)\MSBuild\14.0\Bin\amd64” (we had to add these when MSBuild went OOB)

3. Those redirect to the real Microsoft.Data.Entity.targets which still ships as part of the .NET Framework and in which EntityDeploy is defined

4. The implementation lives in Microsoft.Data.Entity.Build.Tasks.dll which is part of .NET Framework as well. The work it does is actually straightforward:

• Splits the edmx file into separate files for the csdl, ssdl and msl sections
• Sets their logical names, and embeds them

[SidShetye]

@livarcocc The dotnet cli should manage all this itself, perhaps calling msbuild/platform extensions as needed. This is fragmenting our CI scripts because a .sln with multiple .net framework, standard and core binaries (some multi targeted) will now be having some very ugly corner cases to handle instead of elegant dotnet ... commands at the solution root.

In the meantime, it would REALLY help if you could at least throw a fatal exception when building with dotnet CLI and you encounter edmx's. We burnt way more time than needed to figure out and are seeing this issue only thanks to some very specific and desperate google searches.

My team is strongly of the opinion that the tooling should be handling all this internally instead of passing this onto end users - that too as silent runtime failures.

[mario-mestrovic]

@SidShetye I agree that the dotnet cli should manage this itself especially if the build machine already has full msbuild installed. It's a consistency thing, if I can just press run from VS and it works I should be able to do the same with a cli command.

[SidShetye]

@livarcocc what is the plan of action? As more projects migrate over this is going to frustrate users. Should be possible for dotnet to reuse current EF build tooling that works with EDMXs

[livarcocc]

We currently don't have plans to support these tools from the CLI. In this case, the workaround is to use msbuild to build your projects.

Or switch to using EF core.

[dasMulli]

I believe the remaining work for this is already tracked at dotnet/ef6#231

[SP-SuperPoney]

I've done it this way while waiting for a better solution :
(https://stackoverflow.com/questions/45674708/unable-to-load-the-specified-metadata-resource-release-vs-debug-build/62963199#62963199)

[MisinformedDNA]

I believe the remaining work for this is already tracked at dotnet/ef6#231

Apparently no, since that's now closed, and this still remains an issue.