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

AleksandrAlbert commented 6 years ago

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: 5695315371

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

@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:

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>

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)
Those redirect to the real Microsoft.Data.Entity.targets which still ships as part of the .NET Framework and in which EntityDeploy is defined
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 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

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.