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

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

Open
AleksandrAlbert opened this Issue Dec 8, 2017 · 11 comments

Comments

Projects
None yet
6 participants
@AleksandrAlbert
Copy link

AleksandrAlbert commented Dec 8, 2017

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 comment has been minimized.

Copy link
Member

livarcocc commented Dec 8, 2017

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?

@livarcocc livarcocc added this to the Discussion milestone Dec 8, 2017

@livarcocc livarcocc self-assigned this Dec 8, 2017

@AleksandrAlbert

This comment has been minimized.

Copy link

AleksandrAlbert commented Dec 8, 2017

@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

This comment has been minimized.

Copy link
Member

livarcocc commented Dec 8, 2017

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

This comment has been minimized.

Copy link

AleksandrAlbert commented Dec 8, 2017

@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

This comment has been minimized.

Copy link
Member

livarcocc commented Dec 8, 2017

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

This comment has been minimized.

Copy link
Member

divega commented Dec 9, 2017

@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>
  1. 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)

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

  3. 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

@AleksandrAlbert AleksandrAlbert changed the title dotntet cli does not embed csdl,msl, or ssdl files dotnet cli does not embed csdl,msl, or ssdl files Mar 2, 2018

@SidShetye

This comment has been minimized.

Copy link

SidShetye commented May 22, 2018

@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

This comment has been minimized.

Copy link

mario-mestrovic commented May 22, 2018

@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

This comment has been minimized.

Copy link

SidShetye commented Jun 14, 2018

@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

This comment has been minimized.

Copy link
Member

livarcocc commented Jun 15, 2018

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

This comment has been minimized.

Copy link
Contributor

dasMulli commented Jun 16, 2018

I believe the remaining work for this is already tracked at aspnet/EntityFramework6#231

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