ef6: Migrations don't compile. 'Unable to create a manifest resource name for %MIGRATION_FILE%.resx'. Could not find a part of the path '%MIGRATION_FILE%%.cs'
We are getting the following build errors when trying to compile our EF6 project on .NET Core Preview 9 (also tested nightly build 6.3.0-rc1-19455-01, tested both Windows and Mac).
Microsoft.CSharp.CurrentVersion.targets(100, 9): [MSB3041] Unable to create a manifest resource name for "Migrations\201806250240525_MigrationName1.resx". Could not find a part of the path 'C:\...PathToProject...\Migrations\Migrations\###############_MigrationName1.cs'.
Microsoft.CSharp.CurrentVersion.targets(100, 9): [MSB3041] Unable to create a manifest resource name for "Migrations\201806250240525_MigrationName2.resx". Could not find a part of the path 'C:\...PathToProject...\Migrations\Migrations\###############_MigrationName2.cs'.
...
Microsoft.CSharp.CurrentVersion.targets(100, 9): [MSB3041] Unable to create a manifest resource name for "Migrations\201806250240525_MigrationName5.resx". Could not find a part of the path 'C:\...PathToProject...\Migrations\Migrations\###############_MigrationName5.cs'.
It seems the paths being looked for includes ‘Migrations\Migrations\’ twice, which indeed doesn’t exist.
Further technical details
EF version: Tried both 6.3.0-preview9-19423-04 and 6.3.0-rc1-19455-01 Database Provider: System.Data.SqlClient (SQL Server) Operating system: Tried both Windows 10 and MacOS Mojave 10.14.6 IDE: Rider 2019.2.2
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 15 (10 by maintainers)
@divega confirmed that putting the files in the root directory avoids the problem – though obviously not an acceptable workaround since we have tens of migrations and would change + pollute the project structure.
The workaround of manually adding the dependent-upon references also avoids the issue, as mentioned above (more acceptable):
The resource names will be wrong (as they were in preview8) causing
new ResourceManager(typeof(MyMigrationClass))to failHmm… It actually doesn’t appear to be fixed at all. The workaround is still required on .NET Core projects too: