Sdk: dotnet publish won't embed edmx resources

[lampersky]

Steps to reproduce

1. Create new ASP.NET Core Web Application (.NET Framework),
2. Add new Project to solution (Visual C# > Windows Classic Desktop) and select Class Library (.NET Framework),
3. Add EntityFramework 6.1.3 as a reference to previously added class library,
4. Add new Item to class library (Visual C# Items > Data > ADO.NET Entity Data Model),
5. Choose Model Contents -> EF Designer from database, select any of your database, also select that you want to use "Entity Framework 6.x", and choose at least one table to include in your model, in this step VS will create EDMX file,
6. Add reference to project "class library" from WebApplication,
7. Build whole solution with Visual Studio, go to bin directory in Class Library folder, and open this library with any resource viewer (resedit, ILSpy), notice that few resources are embedded (*.msl, *.csdl, *.ssdl),
8. Restore nuget packages "nuget restore Solution.sln" and publish solution with "dotnet publish Solution.sln", go to bin directory in Class Library folder, and open this library with any resource viewer (resedit, ILSpy), notice that embedded resources are missing.

Expected behavior

"dotnet publish" and "MSBuild" should produce same libraries.

Actual behavior

Class library produced by "dotnet publish" is without embedded resources.

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.4)

Product Information:
Version: 1.0.4
Commit SHA-1 hash: af1e6684fd

Runtime Environment:
OS Name: Windows
OS Version: 6.3.9600
OS Platform: Windows
RID: win81-x64
Base Path: C:\Program Files\dotnet\sdk\1.0.4

nuget output:
NuGet Version: 4.1.0.2450

WebApplication1.zip

[dhaligas]

getting this same issue .. is this not supported?

[lampersky]

@dhaligas If your deployment process is based on "dotnet publish", you can build "Class Library" with MSBuild just before executing "dotnet publish", store somewhere the artifact and replece it in destination directory when "dotnet publish" succeed. But this increase a bit your deployment time and still is only a workaround.

call :ExecuteCmd "%MSBUILD_PATH%" ClassLibrary3.csproj /p:Configuration=%configName%
example
%ProgramFiles(x86)%\MSBuild\14.0\Bin\MSBuild.exe ClassLibrary3.csproj /p:Configuration=Release

[QuantumHive]

I can confirm this. Thank god I found this issue, because I've been banging my head for two days now. I just recently posted an SO question about this. Whenever I do a normal MSBuild, the resources are embedded in the assembly (I've looked with Reflector inside the .dll). But whenever I do dotnet publish -c Release -r win7-x86, the resources are not embedded.

Could someone at Microsoft confirm this please? This issue was opened on June 9th, two months have passed without an official reply?

[lampersky]

I found this issue over a year ago, when our team decided to switch to dotnet core. Every dotnet version seems to be affected, even the latest one 2.0.0.

I created support ticket on Azure a week ago. I will let you know when MS will replay me.

[QuantumHive]

I can confirm that this issue also applies to 2.0.

In our solution, we have multiple class libraries, which we now migrated to netstandard2.0 or net47 (for those that reference EntityFramework 6.1) as target framework.
However, the project that contains the .edmx file cannot be upgraded to the new .csproj style, because the resources are not getting embedded at build. And thus the following exception gets thrown at runtime:

System.Data.Entity.Core.MetadataException: Unable to load the specified metadata resource.

So this project is not migrated and still uses the old .csproj style. However, the issue still arises when doing a publish.

[jonoliver82]

I have the same issue with CI build on TFS deploying to Azure - the resultant library produced at the dotnet publish stage does not have the embedded resources expected, although the library produced prior to this step at the msbuild stage does.

As a workaround I edited the TFS build definition to add a Copy Files task after dotnet publish and before Archive files. The copy files task has the following settings:

Source Folder: $(agent.builddirectory)
Contents: **\Websites\Product.Data.EntityFramework6\bin\Debug\Product.Data.EntityFramework6.dll
Target Folder: $(Build.ArtifactStagingDirectory)
Overwrite: True
Flatten Folders: True

[QuantumHive]

@jonoliver82 your example is specific to your case. Your assembly is called Product.Data.EntityFramework6, obviously other people's assemblies have different names. Also you're copying from the Debug folder (meaning you're relying on MSBuild before publishing). I don't think it's wise to copy a debug build to a publish and deploy that on Azure (meaning it's a production build).
In any case, the workaround is not solid and Microsoft should've confirmed this bug already and fix it in a future release.

In our case we're not even using dotnet publish anymore and changed the build script in a manner that MSBuild is used.

[jonoliver82]

@QuantumHive Obviously people will have different assembly names and would change it as required.
I was merely building off the comment by @lampersky of using the (correct) output from msbuild that has the embedded resources, which in my build definition was already run before dotnet publish in order to build the solution and run the unit tests.

[lampersky]

I have tried to compare what is the difference between "dotnet msbuild" and "msbuild" itself.
Bacause Microsoft says that both commands have the exact same capabilities.
https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-msbuild

I was playing a bit with debugging "msbuild" regarding to this article:
https://blogs.msdn.microsoft.com/visualstudio/2010/07/06/debugging-msbuild-script-with-visual-studio/.

I found that msbuild needs few additional files to run "EntityModelCodeGenerator" correctly.
In msbuild instalation directory there are:

But I can't find these two files in bundled (with dotnet SDK) version of msbuild. Maybe there are more missing files.

[QuantumHive]

@lampersky nice work on finding out that there are missing files in the SDK!
@livarcocc any official confirmation from the team?

[AlphaCreativeDev]

We just encountered this issue too while setting up CI in VSTS. We came up with a workaround for those using VSTS CI. We replaced our ".NET Core" build with a "Visual Studio Build" step and then a publish with ".NET Core". We considered the option @jonoliver82 posted but found this option for VSTS CI.

[AleksandrAlbert]

Also getting this problem of 'dotnet build' not embedding csdl,msl, or ssdl files into my dll. This started happening after I migrated my project from vs2015 to vs2017. Has anyone found a fix to this?

[lampersky]

Please use msbuild instead of "dotnet publish".

Here is an example of msbuild command which creates zip archive:
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\msbuild.exe" WebApplication1\WebApplication1.csproj /p:DeployOnBuild=true /p:Configuration=Release /p:WebPublishMethod=Package /p:DeployTarget=WebPublish /p:PackageAsSingleFile=true /p:DeployIisAppPath="Default Web Site" /p:SolutionDir="." /p:DesktopBuildPackageLocation="c:\tmp\WebApplication1.zip"

[QuantumHive]

What @lampersky suggest is more a workaround rather than a fix. Unfortunately Microsoft did not respond to or confirm this issue. I guess the priority is low since Entity Framework Core will not have a designer anymore.

[AleksandrAlbert]

@QuantumHive I created a new issue and they acknowledged it there https://github.com/dotnet/cli/issues/8193 Hopefully they can find a fix now that they have acknowledged the issue

[livarcocc]

This is something that is explicitly not currently support and not in our plans at the moment. We should track it at dotnet/cli#8193.

[gtrak]

EF Classic has some code built in for this that I've used successfully on linux:

Usage:
https://entityframework-classic.net/overview#database-first.net-core

impl: https://github.com/zzzprojects/EntityFramework-Classic/blob/master/src/Shared/EntityFramework.Community.Shared/UseDatabaseFirst/UseDatabaseFirstManager.cs#L15

[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)