dotnet publish builds the project a second time in Debug configuration when using EF sql generation

dotnet publish is typically used to publish the Release configuration, especially on CI. When using the option to generate EF sql migration scripts during publishing, the project (and its dependencies) is built a second time in the default, Debug configuration. This is wasteful and unexpected. Also, AFAICT this is completely absent from the logs even at the diagnostic level.

Steps to reproduce

For the steps I mostly reuse the EF Getting Started tutorial (https://docs.microsoft.com/en-us/ef/core/get-started/).

1. Prepare the project a. dotnet new web -o EFGetStarted b. cd EFGetStarted c. dotnet add package Microsoft.EntityFrameworkCore.SqlServer d. dotnet new tool-manifest e. dotnet tool install dotnet-ef f. dotnet add package Microsoft.EntityFrameworkCore.Design g. Add Model.cs

     using System.Collections.Generic;
     using Microsoft.EntityFrameworkCore;
   
     namespace EFGetStarted
     {
         public class BloggingContext : DbContext
         {
             public DbSet<Blog> Blogs { get; set; }
             public DbSet<Post> Posts { get; set; }
   
             protected override void OnConfiguring(DbContextOptionsBuilder options)
                 => options.UseSqlServer("_");
         }
   
         public class Blog
         {
             public int BlogId { get; set; }
             public string Url { get; set; }
   
             public List<Post> Posts { get; } = new List<Post>();
         }
   
         public class Post
         {
             public int PostId { get; set; }
             public string Title { get; set; }
             public string Content { get; set; } 
   
             public int BlogId { get; set; }
             public Blog Blog { get; set; }
         }
     }
   

   h. dotnet ef migrations add InitialCreate
2. rm -rf bin for clean slate
3. dotnet publish -c Release
4. ls bin note that Release dir is present, no Debug folder
5. Edit EFGetStarted.csproj. This enables script generation and triggers the issue.

   <ItemGroup>
     <EFMigrations Include="EFGetStarted.BloggingContext" />
   </ItemGroup>
   

6. rm -rf bin
7. dotnet publish -c Release
8. ls bin note that Release and Debug dirs are present and both contain binaries

Further technical details

$>dotnet info
.NET Core SDK (reflecting any global.json):
 Version:   3.1.201
 Commit:    b1768b4ae7

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  18.04
 OS Platform: Linux
 RID:         ubuntu.18.04-x64
 Base Path:   /usr/share/dotnet/sdk/3.1.201/

Host (useful for support):
  Version: 3.1.3
  Commit:  4a9f85e9f8

.NET Core SDKs installed:
  3.1.201 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.App 3.1.3 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.3 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

AFAIS, script generation runs dotnet ef command underneath (GenerateEFSqlScripts task run from Microsoft.NET.Sdk.Publish.TransformFiles.targets), but doesn’t pass any msbuild properties set in the encompassing build. Maybe it should at least pass the Configuration property. It could also additionally pass --no-build. After all we are in a publish, the binaries have just been built. A possible workaround is to do it on our own by using EFMigrationsAdditionalArgs property. But it’s all hard to notice and discover, especially that this whole secondary build is completely absent from the logs.

[bricelam]

👍 Using --no-build would be a nice optimization

[vijayrkn]

ok, Will pass in configuration with the --no-build flag.