Generated migration does not get added to the project.

[isaacabraham]

After you create a migration, you have to manually add it to the solution in order for the dotnet ef migration command to work, otherwise it doesn't detect it.

[dsshep]

This is quite challenging, for a few obvious reasons and some more subtle:

• Order of files matters in F#. E.g. these migrations need to be inserted below the declaration of the DbContext.
• There's no easy way of knowing the source file containing the DbContext or if it is the correct DbContext.
• There could be multiple .fsproj files in a single directory.
• Any solution needs to work cross platform which leads onto:
• There doesn't appear to be an easy API for dotnet core to manipulate .fsproj files (Although there is for .NET framework). I may be wrong here?

Having said that, I have attempted this on my fork, you can see the code here: https://github.com/DurdSoft/EFCore.FSharp/blob/db135cf8c8b44891c2281eeb3e94c9276493adb2/src/EFCore.FSharp/Migrations/Design/FSharpMigrationsScaffolder.fs#L62

It relies heavily on string matches and there would no doubt be scenarios that could cause it to trip up.

I'd be interested to see what you think @isaacabraham - you probably have more experience of complex .fsproj files than me - I only F# for a hobby! I've no doubt missed some potential gotchas.

Worth noting there was a previous discussion on this here: #20 but it didn't pick up much steam.

[baronfel]

@DurdSoft few quick notes after briefly looking at your fork. First off, great job knocking out these getting-started issues!

• I'd look at using dotnet-proj-info for 'project file cracking', aka finding out information about the structure and contents of a project file. It's used in several other projects that need information about this and is sorta the go-to for consistent, correct results. It defers to msbuild under the covers so it is consistent with what the rest of the build system sees
• have you thought about enforcing a certain structure on users of EFCore.FSharp? It's definitely possible to have limited glob-includes of f# files based on patterns, so if you required a user to have a fsproj item like <Compile Include="Migrations/*.fs" /> you could then generate strictly-ordered migrations (perhaps by use of a formatted timestamp) and they would be correctly-ordered as long as they appear in a Migrations folder after the DbContexts have been defined.
  • I do this in my work projects that use FluentMigrator along with a quick helper script to template out a new migration and it works great!

[dsshep]

Thank you for the link to that project, that would certainly help us with the file schema. Certainly we could look at how Ionide manages this. I'm not sure about enforcing a structure - EF is already very opinionated!

However, that still leaves a few issues I can think of off the top of my head that make a holistic solution difficult:

• We don't know the file containing the derived DbContext. It seems the compiler doesn't know much about correcting file order (or we would get hints when the project cannot compile due to order - perhaps a naive assumption?) so we'd always have to speculate. Maybe could look at generated .pdb files?
• Multiple .fsproj files in a single directory (which one should be updated?)
• Identifying whether we're adding the first migration or a subsequent one - don't want to add a file twice.

I'm not 100% sure how this works with C#, .NET Framework and EF Core. If I remember correct, the .csproj file for Framework requires files to be listed. It's probably worth doing some investigation there as well.

[isaacabraham]

I think @baronfel idea re: globbed folder is the way to go. Worst case it's a one-off move of the folder in the project hierarchy the first time and after this it'll just work.

[simon-reynolds]

Migrations are created with a timestamp in the filename as is so they would be automatically sorted correctly with globbing
I think that could be the best approach alright