Project-system: Migration "designer" file gets added to csproj with wrong case

[nordvall]

When I perform Add-Migration from Visual Studio, the following files are created in my project directory:

• {datetime}.{migrationname}.cs
• {datetime}.{migrationname}.Designer.cs

These files are also registred in the csproj file for the project (is it really needed?). However, the Designer.cs file is added with lower case 'd', like {datetime}.{migrationname}.designer.cs

This becomes a problem when I try to build my project on a Linux machine in Azure Pipelines:

CSC : error CS2001: Source file '/home/vsts/work/1/s/{project directory}/Migrations/{datetime}.{migrationname}.designer.cs' could not be found. [/home/vsts/work/1/s/{project directory}/{project name}.csproj]

As you know, Linux usually has case sensitive file systems, which consider this file as non-existing.

Steps to reproduce

My setup is a VS Solution with two projects

• myproject.data: A .NET Standard 2.1 Class library project
• myproject.api: An asp.net core 3.0/.net core 3.0 project

1. Create a migration from VS Package Manager Console:

Add-Migration mymigration -Project myproject.data -StartupProject myproject.api

1. Inspect the files produced on disk:

• Migrations\20200131080738_mymigration.cs
• Migrations\20200131080738_mymigration.Designer.cs

1. Inspect the myproject.data.csproj file:

<Compile Include="Migrations\20200131080738_mymigration.cs" />
<Compile Include="Migrations\20200131080738_mymigration.designer.cs" />

1. Notice the case difference between "Designer.cs" and "designer.cs"

If you want you can try to build the project with Azure Pipelines and vmImage: 'ubuntu-latest' in the yaml-file to see the error.

I develop the project on Windows, where everything works fine. The error appears further down the road, when we come to the Azure Pipelines build.

Workaround

I use to manually update the csproj file, and replace "designer" with "Designer".

Further technical details

EF Core version: 3.1.1
Database provider: Microsoft.EntityFrameworkCore.SqlServer
Target framework: .NET Standard 2.1
Operating system:

• Windows 10 (dev machine).
• ubuntu-latest (build agent)
  IDE: Visual Studio 2019 16.3.9
  Microsoft.EntityFrameworkCore.Tools version: 3.1.1

[bricelam]

Weird. Is Visual Studio writing to a regular NTFS drive? (as opposed to a network share or something) Do you have any source control extensions installed that might somehow be interfering with the filename casing?

[nordvall]

It's my company computer and now I left for the weekend, but AFAIK it should be a normal NTFS drive. And just the built-in Git extension.
Du you get a different result when you perform Add-Migration? Are the designer files expected to have a lower case 'd' in their file names on disk?

[ajcvickers]

@nordvall It's not expected. Can you post a project where this behavior is reproduced?

[ajcvickers]

EF Team Triage: Closing this issue as the requested additional details have not been provided and we have been unable to reproduce it.

BTW this is a canned response and may have info or details that do not directly apply to this particular issue. While we'd like to spend the time to uniquely address every incoming issue, we get a lot traffic on the EF projects and that is not practical. To ensure we maximize the time we have to work on fixing bugs, implementing new features, etc. we use canned responses for common triage decisions.

[nordvall]

Sorry for not getting back in time. I was also having problems reproducing the behaviour in a blank project.
However, I realized that the behaviour is enabled by having these lines in the csproj of the data/model project:

<ItemGroup>
    <Compile Remove="Migrations\**" />
    <EmbeddedResource Remove="Migrations\**" />
    <None Remove="Migrations\**" />
</ItemGroup>

I guess this forces the tooling to add the migration files into the csproj explicitly.

Some tooling must have added these "remove statements" into the csproj in some moment in time. (I think my original project was upgraded from ef core 2).

Here is a project that reproduces this issue: https://github.com/nordvall/EfCoreMigrationLinuxBug

[finalcut]

I had the same issue occur and the same itemgroup seemed to be in the code.

They seem to have been automatically added by VS 2019 when we went back and deleted all of the existing migrations so we could "start fresh" From then on out, with those lines in the .csproj file all new migrations that are created have a file named like Migrations\xxx.Designer.cs but they are automatically added to the .csproj file like:

<Compile Include="Migrations\xxx.designer.cs" />

Which, as OP states, breaks the build once it reaches the linux server (in my case a gitlab server).

Removing the five lines

<ItemGroup>
    <Compile Remove="Migrations\**" />
    <EmbeddedResource Remove="Migrations\**" />
    <None Remove="Migrations\**" />
</ItemGroup>

and then creating our migrations fixed the problem. No compile lines are added to the csproj everything is working properly again

[finalcut]

@ajcvickers hopefully the information provided in the prior to comments will be enough to get this issue re-opened

[nordvall]

I think my original issue was also related to deleting some existing migrations and then creating new ones.

But I'm wondering if this might actually be a Visual Studio bug? I remember I searched the efcore codebase and couldn't find any place that a csproj file is parsed and modified "manually" by efcore. Or maybe efcore is using some Visual Studio API call to add new files into the project? Then I might have missed that.

[ajcvickers]

@davkean This looks to us like the project system is normalizing the filename to lower case when explicitly adding the new file to a csproj where there is a <Compile Remove="Migrations\**" /> that prevents the file from being picked up implicitly. This causes issues for case-sensitive file systems. Thouights?

[davkean]

@finalcut Thank-you for the great repro project! It helped me track down the bug quickly. I've fixed it and the fix will appear in VS 16.6 Preview 2.

[davkean]

I've moved this over to project-system.

[finalcut]

all credit to @nordvall for the repo project but thanks for fixing it @davkean

[davkean]

This fix has been merged.