Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
dotnet cli does not embed csdl,msl, or ssdl files #8193
Steps to reproduce
Both Visual Studio and cli should embed csdl, msl, and ssdl files into dll as resources.
Only Visual Studio embeds these files. When built through cli, files are not embedded and a Metadata exception is thrown when accessing the model.
.NET Command Line Tools (2.1.2)
Microsoft .NET Core Shared Framework Host
Version : 2.0.3
This problem only began when I moved my project from vs2015 to vs2017. I was able to use the cli just fine before.
@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 was able to find the old project.json in my git history, here it is:
@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:
<EntityDeploy Include="MyModel.edmx"> <Generator>EntityModelCodeGenerator</Generator> <LastGenOutput>Model1.Designer.cs</LastGenOutput> </EntityDeploy>
referenced this issue
Dec 15, 2017
@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
In the meantime, it would REALLY help if you could at least throw a fatal exception when building with
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.