EF 6.3 - Embedded resources issue with new SDK csproj style

I’m moving our projects to the new SDK style, as the first step to a .NET Core migration. After migrating all projects, the one left was the class library which contained the EF code (DbContext, Migrations and so on). All the projects are running on .NET Framework 4.7.2. No .NET Core involved.

With the work done for 6.3 (thanks a lot!) I then went back to it to finally move the project to the new sdk style. These are the steps I made:

1. Switched first to PackageReferences and deleted packages.config
2. Made sure everything was still working (adding migrations, update, run the app)
3. Manually converted the csproj file to the new SDK style. Removed all EmbeddedResource from there. I still have the app.config in the class library
4. Deleted the database and tried running Update-Database and it failed. The error is:

Applying explicit migration: 201909170903584_Init.
System.Resources.MissingManifestResourceException: Could not find any resources appropriate for the specified culture or the neutral culture.  Make sure "EFDemo.Data.Migrations.Init.resources" was correctly embedded or linked into assembly "EFDemo.Data" at compile time, or that all the satellite assemblies required are loadable and fully signed.
   at System.Resources.ManifestBasedResourceGroveler.HandleResourceStreamMissing(String fileName)
   at System.Resources.ManifestBasedResourceGroveler.GrovelForResourceSet(CultureInfo culture, Dictionary`2 localResourceSets, Boolean tryParents, Boolean createIfNotExists, StackCrawlMark& stackMark)
   at System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo requestedCulture, Boolean createIfNotExists, Boolean tryParents, StackCrawlMark& stackMark)
   at System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo culture, Boolean createIfNotExists, Boolean tryParents)
   at System.Resources.ResourceManager.GetString(String name, CultureInfo culture)
   at EFDemo.Data.Migrations.Init.System.Data.Entity.Migrations.Infrastructure.IMigrationMetadata.get_Target()
   at System.Data.Entity.Migrations.DbMigration.GetModel(Func`2 modelAccessor)
   at System.Data.Entity.Migrations.DbMigrator.ApplyMigration(DbMigration migration, DbMigration lastMigration)
   at System.Data.Entity.Migrations.Infrastructure.MigratorLoggingDecorator.ApplyMigration(DbMigration migration, DbMigration lastMigration)
   at System.Data.Entity.Migrations.DbMigrator.Upgrade(IEnumerable`1 pendingMigrations, String targetMigrationId, String lastMigrationId)
   at System.Data.Entity.Migrations.Infrastructure.MigratorLoggingDecorator.Upgrade(IEnumerable`1 pendingMigrations, String targetMigrationId, String lastMigrationId)
   at System.Data.Entity.Migrations.DbMigrator.UpdateInternal(String targetMigration)
   at System.Data.Entity.Migrations.DbMigrator.EnsureDatabaseExists(Action mustSucceedToKeepDatabase)
   at System.Data.Entity.Migrations.DbMigrator.Update(String targetMigration)
   at System.Data.Entity.Infrastructure.Design.Executor.Update.<>c__DisplayClass0_0.<.ctor>b__0()
   at System.Data.Entity.Infrastructure.Design.Executor.OperationBase.Execute(Action action)
Could not find any resources appropriate for the specified culture or the neutral culture.  Make sure "EFDemo.Data.Migrations.Init.resources" was correctly embedded or linked into assembly "EFDemo.Data" at compile time, or that all the satellite assemblies required are loadable and fully signed.

If I leave the EmbeddedResource files as they were in the old .csproj: EmbeddedResource Include...., then the build fails as these files are already included with the new SDK style.

It goes on to suggest me to add <EnableDefaultCompileItems>false</EnableDefaultCompileItems>, which I really don’t want to.

Out of curiosity, I added a new migration, and I noticed that it updated the .csproj file with the new resource file, but instead of Include it used Update on the EmbeddedResource. I re-introduced manually all of the migrations with Update and then both EF and VS were happy and running Update-Database works.

I saw this issue #1245 and #1234 but couldn’t get much out of it. When I add a new migration, I don’t get the “generic” glob pattern added, but instead the exact migration.

I have created a repro, where you can see the issue. The repro contains 4 migrations in it. https://github.com/joaopgrassi/ef63netfx-sdkstyle-migrations (you can check the commit history to see the steps I made)

1. Try running the update-database:

Update-Database -ConnectionString  "Data Source=(LocalDb)\MSSQLLocalDB;Initial Catalog=MoviesDb;Integrated Security=SSPI" -ConnectionProviderName  "System.Data.SqlClient" -StartUpProjectName "EFDemo.Data" -ProjectName "EFDemo.Data" -Verbose

It will fail with the error above. To fix it, uncomment the resources in .csproj file. The command will work now.

After being able to create the database, try making any change to the Movie entity and add a new migration:

Add-Migration -Name NewMigration -ConnectionString  "Data Source=(LocalDb)\MSSQLLocalDB;Initial Catalog=MoviesDb;Integrated Security=SSPI" -ConnectionProviderName  "System.Data.SqlClient" -StartUpProject "EFDemo.Data" -ProjectName "EFDemo.Data" -Verbose

1. Check out the .csproj file. This will be added:

  <ItemGroup>
    <EmbeddedResource Update="Migrations\201909171132226_NewMigration.resx">
      <DependentUpon>201909171132226_NewMigration.cs</DependentUpon>
    </EmbeddedResource>
  </ItemGroup>

Further technical details

EF version: 6.3.0-rc1-19458-04 Database Provider: EntityFramework.SqlServer Operating system: Windows 10 IDE: Visual Studio 2019 Enterprise v16.2.5

[CZEMacLeod]

@Timores I had this issue when it first came out; however, using <EmbeddedResourceUseDependentUponConvention>true</EmbeddedResourceUseDependentUponConvention> seems to work as expected. I have projects targeting net461 to net48, and some multitargeting net472 and netstandard2.1 and it works in VS2019 and VS2022 for me. I have had the net5 sdk and now net6 sdk installed on my dev machine and on my build server and not had any problems.

[bricelam]

Was VS the problem all along

Yes, it was a bug in MSBuild