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
marchy
All 15 comments
Could you provide a simplified project to help us debug?
bricelam
on 5 Sep 2019
Hi Brice, not sure how we would be able to do that without significant effort.
Happy to try looking into various things and providing feedback on here though. Let us know what you'd like us to try out and we'll make sure we turn things around to the team as a top-priority.
marchy
on 5 Sep 2019
What projects are involved and what framework do they target? What does your DbMigrationsConfiguration-derived class look like? What project is it in?
bricelam
on 5 Sep 2019
Project is a library project, being upgraded from 'net472' to 'netstandard2.1' target framework.
.csproj file:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.1</TargetFramework>
<LangVersion>7.3</LangVersion>
<AssemblyName>XXXX.XXXX.Domain</AssemblyName>
<OutputType>Library</OutputType>
<PackageId>XXXX.XXXX.Domain</PackageId>
<RuntimeIdentifiers>win7-x86;win8-x86;win10-x64</RuntimeIdentifiers>
<NetStandardImplicitPackageVersion>1.6.1</NetStandardImplicitPackageVersion>
<GenerateAssemblyConfigurationAttribute>false</GenerateAssemblyConfigurationAttribute>
<GenerateAssemblyCompanyAttribute>false</GenerateAssemblyCompanyAttribute>
<GenerateAssemblyProductAttribute>false</GenerateAssemblyProductAttribute>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="..\World.NET\World.NET.Core\World.NET.Core.csproj" />
<ProjectReference Include="..\World.NET\World.NET.Data\World.NET.Data.csproj" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="AutoMapper" Version="6.2.2" />
<PackageReference Include="EntityFramework" Version="6.3.0-rc1-19455-01" />
<PackageReference Include="GeoCoordinate.NetStandard1" Version="1.0.1" />
<PackageReference Include="Microsoft.AspNetCore" Version="2.2.0" />
<PackageReference Include="Microsoft.AspNetCore.Hosting" Version="2.2.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="1.1.1" />
<PackageReference Include="Microsoft.Extensions.Configuration.EnvironmentVariables" Version="2.2.4" />
<PackageReference Include="Microsoft.Extensions.Configuration.Json" Version="2.2.0" />
<PackageReference Include="Microsoft.Extensions.Options.ConfigurationExtensions" Version="2.2.0" />
<PackageReference Include="Migrator.EF6.Tools" Version="2.1.0" PrivateAssets="All" />
<!--<PackageReference Include="NeinLinq.EFCore" Version="1.7.0" />-->
<PackageReference Include="NeinLinq.EntityFramework" Version="3.1.1" />
<PackageReference Include="Newtonsoft.Json" Version="12.0.2" />
<PackageReference Include="PushSharp" Version="4.0.10" />
<PackageReference Include="System.Data.SqlClient" Version="4.7.0-rc1.19454.13" />
<PackageReference Include="Twilio" Version="5.6.5" />
</ItemGroup>
<ItemGroup Condition=" '$(TargetFramework)' == 'net47' ">
<Reference Include="System" />
<Reference Include="Microsoft.CSharp" />
<PackageReference Include="System.ValueTuple" Version="4.5.0" />
</ItemGroup>
<ItemGroup>
<DotNetCliToolReference Include="Migrator.EF6.Tools" Version="2.1.0" />
</ItemGroup>
<!-- REMOVED for .NET Core 3.0 migration -->
<!-- <ItemGroup>-->
<!-- <Reference Include="Microsoft.AspNetCore.Hosting.Abstractions">-->
<!-- <HintPath>bin\Debug\net462\Microsoft.AspNetCore.Hosting.Abstractions.dll</HintPath>-->
<!-- </Reference>-->
<!-- </ItemGroup>-->
</Project>
DbMigrationsConfiguration-derived class (inner class of DbContext-derived class inside library project):
namespace XXXX.XXXX.Domain.Data {
[DbConfigurationType( typeof(EF6DatabaseConfig) )]
public partial class EF6DatabaseContext : DbContext {
...
public class EF6MigrationConfiguration : DbMigrationsConfiguration<EF6DatabaseContext> {
public EF6MigrationConfiguration() {
AutomaticMigrationDataLossAllowed = false;
AutomaticMigrationsEnabled = false;
CommandTimeout = 5 /*minutes*/ * 60 * 1000;
}
}
}
}
This is further up consumed by several projects (console apps and web apps) – but the compilation of the library project itself fails on its own when compiled in isolation.
marchy
on 5 Sep 2019
@divega I'm starting to think microsoft/msbuild#4488 wasn't fixed for .NET Standard projects. I'm not sure how severe it is though since the tools (Add-Migration, etc.) won't actually work on .NET Standard projects either...
@marchy Does it work if you target netcoreapp3.0 instead of netstandard2.1?
bricelam
on 5 Sep 2019
Hmm... It actually doesn't appear to be fixed at all. The workaround is still required on .NET Core projects too:
<ItemGroup>
<EmbeddedResource Update="Migrations\*.resx">
<DependentUpon>%(FileName).cs</DependentUpon>
</EmbeddedResource>
</ItemGroup>
Hah that's the issue. Adding the manual EmbeddedResource/DependentUpon tags manually for the affected migrations resolves the compilation error.
Strangely however it only raises this issue on 5 of our migrations – even though we have 60+ in the project.
ALSO: 'netstandard2.1' / 'netcoreapp3.0' did not affect things. Both work or not with/without the workaround.
marchy
on 5 Sep 2019
shutdown256
on 5 Sep 2019
@shutdown256, @bricelam So my understanding is that the convention added by the fix to https://github.com/microsoft/msbuild/issues/4488 only fails when the files are inside a folder, which happens to be the default for migrations.
@marchy, perhaps you can verify if this aligns to what you are observing. E.g. if you move the 5 migrations out outside of the Migrations folder, does that help?
cc @ajcvickers.
divega
on 6 Sep 2019
@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):
<ItemGroup>
<!-- TEMP: workaround for https://github.com/microsoft/msbuild/issues/4488 -->
<EmbeddedResource Update="Migrations\###############_MigrationName1.resx">
<DependentUpon>###############_MigrationName1.cs</DependentUpon>
</EmbeddedResource>
....
<EmbeddedResource Update="Migrations\###############_MigrationName5.resx">
<DependentUpon>###############_MigrationName5.cs</DependentUpon>
</EmbeddedResource>
</ItemGroup>
~Another workaround: set the property~
<EmbeddedResourceUseDependentUponConvention>false</EmbeddedResourceUseDependentUponConvention>
~In your project (or in a Directory.Build.props for all of your projects).~
That can cause other problems, ~but if your project was building successfully with preview8, those shouldn't affect you.~ and apparently does, see @bricelam's comment below.
rainersigwald
on 6 Sep 2019
Beware, setting EmbeddedResourceUseDependentUponConvention to False will make it fail at run time.
bricelam
on 6 Sep 2019
@bricelam wait, that's concerning! What causes the failure? That should just revert back to preview8 behavior.
rainersigwald
on 6 Sep 2019
The resource names will be wrong (as they were in preview8) causing new ResourceManager(typeof(MyMigrationClass)) to fail
bricelam
on 6 Sep 2019
Duplicate of microsoft/msbuild#4695
bricelam
on 6 Sep 2019
Related issues
hungdqht
·
3Comments
PhilPJL
·
7Comments
mistachkin
·
5Comments
steamwings
·
7Comments
divega
·
3Comments
Most helpful comment
@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):